Common use of Requisiti tecnico-funzionali del servizio Clause in Contracts

Requisiti tecnico-funzionali del servizio. Il servizio di “Penetration testing” dovrà fornire alle Amministrazioni un processo operativo di analisi e valutazione dei punti deboli relativi ad una infrastruttura IT. Il servizio, condotto su più fasi e mediante l’adozione di adeguati strumenti, si configura nella simulazione di un attacco informatico al sistema da parte di un utente malintenzionato al fine di rilevare la presenza di eventuali falle e vulnerabilità al suo interno. Verranno fornite il maggior numero di informazioni sulle vulnerabilità che hanno permesso l'accesso non autorizzato al sistema con una stima chiara sulle capacità di difesa e sul livello di penetrazione raggiunto. A titolo esemplificativo vengono di seguito indicate le eventuali vulnerabilità utilizzabili a scopi malevoli: ⮚ vulnerabilità interne al sistema: che permetterebbero l’accesso sia ad utenti autorizzati che non autorizzati; ⮚ vulnerabilità esterne al sistema: relative al modo in cui una organizzazione si connette a Internet e ad altri sistemi esterni. Include server, host, dispositivi e servizi di rete; ⮚ vulnerabilità delle applicazioni web e mobile: che deriverebbero da pratiche non sicure nella esecuzione di un’applicazione, di un sito web, di un APP. ⮚ vulnerabilità delle reti wireless: che permetterebbero l’accesso a dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione accesso e i dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione. ⮚ vulnerabilità delle API: relative al corretto funzionamento delle logiche applicative soprattutto per quanto riguarda le meccaniche di autenticazione e autorizzazione. ⮚ vulnerabilità degli IoT: relative al corretto funzionamento di tali infrastrutture allo scopo di estrarre informazioni o comprometterne il funzionamento. ⮚ vulnerabilità dei dati sensibili dovute ad un attacco di phising (Phishing): relative alla valutazione della suscettibilità dei dipendenti agli attacchi di “ingegneria sociale”. Le vulnerabilità possono quindi riguardare sistemi operativi, servizi, configurazioni, server, endpoint, applicazioni Web, reti wireless, dispositivi di rete, dispositivi mobili. Il servizio di “Penetration Testing” potrà essere svolto dal Fornitore mediante l’adozione di tecnologie e strumenti automatici senza oneri aggiuntivi per l’Amministrazione. Il fornitore dovrà svolgere il servizio di “Penetration testing” mediante l’adozione di metodologie e standard di mercato di riferimento quali: ⮚ OWASP Testing Guide; ⮚ OSSTMM; ⮚ Penetration Testing Execution Standard. Di seguito le fasi che il servizio di “penetration testing” dovrà prevedere sono almeno le seguenti fasi:

Requisiti tecnico-funzionali del servizio. Il servizio di “Penetration testingVulnerability Assessment” dovrà fornire consentire alle Amministrazione di identificare lo stato di esposizione alle vulnerabilità mediante la raccolta di informazioni concernente i servizi erogati, le applicazioni, l’architettura e le componenti tecnologiche. Il servizio è indirizzato principalmente alle Amministrazione che, in fase di definizione della strategia di sicurezza, necessitano di delineare un iniziale valutazione dello stato di sicurezza del sistema informativo e dello stato di esposizione alle vulnerabilità. Il servizio deve consentire una verifica dinamica della sicurezza dei dispositivi di rete, del software di base e delle applicazioni dell’Amministrazione allo scopo di identificare eventuali vulnerabilità, configurazioni di sicurezza errate, carenze sui livelli di protezione attivi, applicazioni web e serventi che espongano il contesto ad attacchi interni ed esterni. Il servizio dovrà essere modulare e configurabile per il singolo host o applicazione. Gli esiti del servizio consentiranno quindi alle Amministrazioni di elaborare una baseline iniziale (AS-IS) del livello di vulnerabilità e di esposizione del sistema informativo necessaria alla definizione della specifica strategia di sicurezza informatica. Tale baseline informativa dovrà essere verificata nuovamente nel momento in cui dovessero verificarsi cambiamenti strutturali nell’architettura dei sistemi, della rete o delle applicazioni a seguito ad esempio di: • una evoluzione dei sistemi e delle applicazioni del sistema informativo dell’Amministrazione dovuto ad un processo operativo rinnovamento tecnologico o all’introduzione di analisi vincoli normativi e/o organizzativi; • una evoluzione del modello di erogazione dei servizi dell’Amministrazione mediante la migrazione dei sistemi e valutazione dei punti deboli relativi ad una infrastruttura ITdelle applicazioni verso un modello “On-premise”, “Ibrido” o di tipo “Cloud”. Il servizioservizio dovrà consentire una verifica dinamica della sicurezza dei dispositivi di rete dell’Amministrazione allo scopo di identificare eventuali vulnerabilità, condotto su più fasi e mediante l’adozione configurazioni di adeguati strumentisicurezza errate, si configura nella simulazione carenze sui livelli di un attacco informatico al sistema da parte protezione attivi che espongano il contesto ad attacchi interni ed esterni. Per la raccolta di un utente malintenzionato tali informazioni il Fornitore potrà avvalersi di strumenti automatizzati senza oneri aggiuintivi per l’Amministrazione al fine di rilevare la presenza di eventuali falle e vulnerabilità al suo internole potenziali vulnerabilità. Verranno fornite il maggior numero di informazioni sulle vulnerabilità che hanno permesso l'accesso Gli strumenti dovranno essere configurati in modo da non autorizzato al sistema con una stima chiara sulle capacità di difesa e sul livello di penetrazione raggiunto. A titolo esemplificativo vengono di seguito indicate le eventuali vulnerabilità utilizzabili risultare intrusivi (a scopi malevoli: ⮚ vulnerabilità interne al sistema: che permetterebbero l’accesso sia ad utenti autorizzati meno che non autorizzati; ⮚ vulnerabilità esterne al sistema: relative al modo in cui una organizzazione si connette a Internet e ad altri sistemi esterni. Include server, host, dispositivi e servizi di rete; ⮚ vulnerabilità delle applicazioni web e mobile: che deriverebbero da pratiche non sicure nella esecuzione di un’applicazione, di un sito web, di un APP. ⮚ vulnerabilità delle reti wireless: che permetterebbero l’accesso a dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione accesso e i dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione. ⮚ vulnerabilità delle API: relative al corretto funzionamento delle logiche applicative soprattutto per quanto riguarda le meccaniche di autenticazione e autorizzazione. ⮚ vulnerabilità degli IoT: relative al corretto funzionamento di tali infrastrutture allo scopo di estrarre informazioni o comprometterne il funzionamento. ⮚ vulnerabilità dei dati sensibili dovute ad un attacco di phising (Phishing): relative alla valutazione della suscettibilità dei dipendenti agli attacchi di “ingegneria sociale”. Le vulnerabilità possono quindi riguardare sistemi operativi, servizi, configurazioni, server, endpoint, applicazioni Web, reti wireless, dispositivi di rete, dispositivi mobilisia espressamente concordato con l’Amministrazione). Il servizio dovrà prevedere almeno le fasi sotto elencate. a. Pianificazione. b. Esecuzione. ⮚ individuazione delle vulnerabilità svolta al fine di “Penetration Testing” potrà collezionare, tramite un set opportuno di strumenti automatizzati e correttamente configurati, una lista delle potenziali vulnerabilità note a cui potrebbero essere svolto dal Fornitore soggetti i sistemi analizzati. Tale fase dovrà adattarsi al contesto infrastrutturale specifico ed alle peculiari vulnerabilità associate allo specifico modello di trasporto; ⮚ esecuzione delle attività secondo un approccio sia di tipo black box (senza ausilio di credenziali) che di tipo grey box (con ausilio di credenziali); ⮚ network e service discovery, con scansione della rete alla ricerca dei nodi attivi; ⮚ identificazione delle tecnologie adottate e delle relative versioni dei servizi in esecuzione; ⮚ individuazione delle vulnerabilità applicative mediante l’adozione discovery e testing delle URL, form HTML, componenti Javascript, Ajax, ecc.; ⮚ verifiche atte a valutare anche la robustezza di infrastrutture Wi-Fi e access point ad uso del personale dipendente dell’Amministrazione e del personale esterno; ⮚ individuazione di tecnologie e strumenti automatici senza oneri aggiuntivi per l’Amministrazione. Il fornitore dovrà svolgere il servizio in ambienti non idonei, con conseguente esposizione di “Penetration testing” mediante l’adozione di metodologie e standard di mercato di riferimento quali: ⮚ OWASP Testing Guiderischi; ⮚ OSSTMMmancanza o non corretta implementazione di tecnologie di prevenzione e riconoscimento di possibili attacchi (sistemi IDS, sistemi IPS, attività di monitoraggio dei log); ⮚ Penetration Testing Execution Standard. Di seguito le fasi che il servizio utilizzo di “penetration testing” dovrà prevedere sono almeno le seguenti fasi:tecnologie in modi impropri. c. Prioritizzazione delle vulnerabilità e verifica dei risultati.

Requisiti tecnico-funzionali del servizio. Il servizio di “Penetration testingCompliance normativa” dovrà fornire consentire alle Amministrazioni un processo operativo di analisi e valutazione dei punti deboli relativi ad una infrastruttura supporto nell’attuazione degli adempimenti del GDPR (General Data Protection Regulation - Regolamento UE 2016) applicato all’ambito del perimentro IT. Il servizioservizio basato su un approccio metodologico, condotto su più fasi e mediante dovrà prevedere senza oneri aggiuntivi per l’Amministrazione l’adozione di adeguati strumenti, si configura nella simulazione di un attacco informatico al sistema da parte di un utente malintenzionato al fine di rilevare strumenti e la presenza di eventuali falle e vulnerabilità al suo interno. Verranno fornite il maggior numero competenze specifiche ed è volto a sviluppare un Sistema di informazioni sulle vulnerabilità che hanno permesso l'accesso non autorizzato al sistema con una stima chiara sulle capacità di difesa e sul livello di penetrazione raggiunto. A titolo esemplificativo vengono di seguito indicate le eventuali vulnerabilità utilizzabili a scopi malevoligestione della Privacy che: ⮚ vulnerabilità interne al sistema: che permetterebbero l’accesso sia ad utenti autorizzati che non autorizzatigarantisca all’Amministrazione l’adozione di un processo per assicurare e mantenere la conformità alla normativa sul lungo periodo; ⮚ vulnerabilità esterne al sistema: relative al modo sia capace di porre in cui una organizzazione si connette a Internet e ad altri sistemi esterni. Include server, host, dispositivi e servizi essere le azioni necessarie per garantire la mitigazione del rischio di retenon conformità; ⮚ vulnerabilità delle applicazioni web e mobile: che deriverebbero consenta di trasformare la privacy da pratiche non sicure nella esecuzione un adempimento di un’applicazione, di un sito web, di un APP. ⮚ vulnerabilità delle reti wireless: che permetterebbero l’accesso a dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione accesso e i dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione. ⮚ vulnerabilità delle API: relative al corretto funzionamento delle logiche applicative soprattutto per quanto riguarda le meccaniche di autenticazione e autorizzazione. ⮚ vulnerabilità degli IoT: relative al corretto funzionamento di tali infrastrutture allo scopo di estrarre informazioni o comprometterne il funzionamento. ⮚ vulnerabilità dei dati sensibili dovute legge ad un attacco abilitatore “mandatorio”, mediante un’analisi del modello di phising (Phishing): relative alla valutazione della suscettibilità maturità dei dipendenti agli attacchi processi di “ingegneria sociale”. Le vulnerabilità possono quindi riguardare sistemi operativi, servizi, configurazioni, server, endpoint, applicazioni Web, reti wireless, dispositivi di rete, dispositivi mobili. trattamento dei dati; Il servizio di “Penetration Testing” potrà Compliance normativa”, in relazione al perimetro IT dell’Amministrazione, dovrà inoltre consentire: ⮚ la valutazione delle principali fonti di rischio di non conformità cui l’Amministrazione è soggetta. Individuazione quindi delle norme, regole e i principi rilevanti per l’Amministrazione e traduzione di tali leggi in regole e procedure che dovranno guidare lo svolgimento dell’operatività della stessa. In tale ambito dovrà essere svolto posta l’attenzione ogni volta che vengono emessi una nuova normativa, un nuovo regolamento o un nuovo standard al quale attenersi, da parte delle istituzioni, delle associazioni di categoria, degli organismi di vigilanza o dell’Amministrazione stessa; ⮚ la raccolta e analisi della documentazione disponibile e delle eventuali evidenze/aree di approfondimento; ⮚ la verifica tramite assessement della situazione corrente, con riguardo alle modifiche/cambiamenti richiesti dalla normativa vigente, individuazione dei processi impattati e che potrebbero risultare quindi esposti al rischio di non conformità, valutando anche il grado di rischio di tale esposizione; ⮚ l’identificazione dei requisiti GDPR per i diversi macro ambiti (es. governance, processi e metodologie, IT/sicurezza); ⮚ la definizione delle politiche e le procedure che dovranno essere poste in essere per contrastare efficacemente i rischi individuati; ⮚ l’elaborazione di un piano periodico di verifiche di conformità, al fine di controllare lo stato dell’arte, l’effettiva applicazione degli adeguamenti organizzativi/operativi resisi necessari, il grado di disallineamento e le eventuali carenze nella gestione dei rischi dell’Amministrazione; ⮚ la predisposizione di interventi correttivi, nuovi processi informativi o di formazione, qualora non siano risultati sufficienti/adeguati; ⮚ l’elaborazione di reportistica periodica e documentazione relativa alle varie attività di compliance; ⮚ il supporto allo sviluppo delle competenze e delle professionalità necessarie a garantire un’efficace applicazione delle regole e dei processi definiti, tramite un adeguato processo di comunicazione e formazione del personale dell’Ammnistrazione. In particolare si indicano a titolo semplificativo e non esaustivo le principali attività nell’ambito del servizio: ⮚ a fronte del registro dei trattamenti dei dati personali, della classificazione dei dati e della valutazione dei rischi: • indirizzare gli aspetti IT conseguenti alle politiche di retention dei dati; • valutare gli impatti IT nell’attuazione delle policy dei diritti dell’interessato, identificando le azioni di remediation per il superamento dei gap individuati; ⮚ individuazione e aggiornamento del perimetro dei sistemi IT interessati dal regolamento GDPR; ⮚ predisposizione della mappatura tra la classificazione dei dati trattati, i requisiti tecnici associati e le soluzioni tecnologiche a supporto al fine di garantire: • un livello minimo di sicurezza per tutti gli applicativi (baseline di sicurezza applicata a tutti i sistemi); • individuazione e applicazione di misure aggiuntive specifiche in base alla natura e criticità del dato, quali mascheramento, cifratura dei Data base, strong authetication, pseudonymisation; ⮚ identificazione dei sistemi che raccolgono i consensi al trattamento dati di soggetti esterni ed interni; valutare la compliance rispetto alla normativa; definire e monitarare eventuali piani di rientro; ⮚ predisposizone di modelli per la documentazione tecnica da produrre verso l’Autorità Garante e gli interessati in caso di data breach; ⮚ supporto per l’identificazione ed il monitoraggio del Piano complessivo di interventi IT volti a garantire la compliance al GDPR; ⮚ elaborazione di sessioni formative di aggiornamento in tema di GDPR; Di seguito si indicano, a titolo esemplificativo e non esaustivo, i deliverables documentali prodotti dal servizio: ⮚ report Assessement e Gap Analisys; ⮚ piano degli interventi; ⮚ registro dei trattamenti; ⮚ scheda per il censimento dei trattatmenti ⮚ framework documentale in ambito privacy (es. procedura data breach, metodologia DPIA, nomine a responsabile, informative); Le risorse impiegate dal Fornitore mediante l’adozione nella erogazione del servizio dovranno possedere specifiche competenze tecnico-giuridiche e professionali ed essere inserite in programmi di tecnologie formazione specifica e strumenti automatici senza oneri aggiuntivi per l’Amministrazione. Il fornitore dovrà svolgere il servizio di “Penetration testing” mediante l’adozione di metodologie e standard di mercato di riferimento quali: ⮚ OWASP Testing Guide; ⮚ OSSTMM; ⮚ Penetration Testing Execution Standard. Di seguito le fasi che il servizio di “penetration testing” dovrà prevedere sono almeno le seguenti fasi:continua, in base alle evoluzioni del contesto in materia.

Requisiti tecnico-funzionali del servizio. Il servizio di “Penetration testingTesting del codice - statico” dovrà fornire consentire alle Amministrazioni l’identificazione delle vulnerabilità software all'interno del codice (sorgente o binario) delle applicazioni nella fase iniziale del ciclo di vita in modo da poterle eliminare prima della distribuzione. Questa tipologia di test (anche detta “white box testing”) deve consentire agli sviluppatori di trovare le vulnerabilità di sicurezza nel codice sorgente durante le prime fasi di sviluppo dell’applicazione garantendo la conformità alle linee guida (ad es. owasp) ed agli standard di codifica senza eseguire effettivamente il codice sottostante. ll termine applicazione viene qui inteso come un processo operativo insieme di righe di codice elaborate in linguaggi diversi ed applicate a contesti di complessità diversa e di differente utilizzo, finalizzate però a rispondere a specifiche esigenze funzionali, ben identificabili nel contesto dell’amministrazione richiedente. Più in generale, il perimetro di applicazione del servizio comprende l’analisi statica del codice sorgente delle seguenti categorie: sviluppo custom interno/esterno, open source, software/librerie di terze parti. Il Fornitore nell’Offerta Tecnica dovrà specificare il tipo di supporto che sarà richiesto all’Amministrazione per l’erogazione del servizio, con esplicita indicazione delle singole attività per cui si richiede supporto ed effort stimato, con particolare riferimento alle tempistiche e alle modalità di consegna del codice oggetto di analisi. L’attività di analisi statica del codice dovrà essere svolta dal Fornitore secondo le best practice internazionali, ed almeno secondo quanto previsto dalle metodologie OWASP e valutazione OSSTMM, e dovrà includere almeno i seguenti controlli: ⮚ Data Validation: verifica della presenza di vulnerabilità che possono riguardare eventuali dati corrotti in ingresso che possono portare a un comportamento anomalo dell’applicazione; ⮚ Control Flow: verifica dei punti deboli relativi rischi collegati all’assenza di specifiche sequenze di operazioni che, se non eseguite in un certo ordine, potrebbero portare a violazioni sulla memoria o l’uso scorretto di determinati componenti; ⮚ Semantico: rilevazione di eventuali problematiche legate all’uso pericoloso di determinate funzioni o API (es. funzioni deprecate); ⮚ Configurazioni: verifica dei parametri intrinseci di configurazione dell’applicazione; ⮚ Buffer Validation: verifica della presenza di buffer overflow exploitabile attraverso la scrittura o lettura di un numero di dati superiore alla reale capacità del buffer stesso. Si precisa che pur essendo il servizio prevalentemente orientato ad una infrastruttura ITapplicazioni in ambiente web, il Fornitore, previo accordo con l’Amministrazione, potrà erogarlo anche su altre tipologie di ambienti, utilizzando il medesimo modello di pricing di seguito definito. Il servizioFornitore nell’ambito del servizio “Testing del codice - statico” dovrà individuare le vulnerabiltà critiche come SQL injection, condotto su più fasi cross-site scripting (XSS), buffer overflow, condizioni di errore non gestite e mediante l’adozione di adeguati strumenti, si configura nella simulazione di potenziali back-door. Di seguito un attacco informatico al sistema da parte di un utente malintenzionato al fine di rilevare la presenza di eventuali falle e vulnerabilità al suo interno. Verranno fornite il maggior numero di informazioni sulle vulnerabilità che hanno permesso l'accesso non autorizzato al sistema con una stima chiara sulle capacità di difesa e sul livello di penetrazione raggiunto. A titolo esemplificativo vengono di seguito indicate le eventuali vulnerabilità utilizzabili elenco delle funzionalità base / strumenti a scopi malevolisupporto: ⮚ identificazione delle vulnerabilità interne al sistema: che permetterebbero l’accesso sia ad utenti autorizzati che non autorizzatiattraverso l’analisi del codice sorgente e indicazione puntuale delle sezioni di codice relative alle vulnerabilità riscontrate; ⮚ verifica dei risultati, individuazione e rimozione dei falsi positivi; ⮚ prioritizzazione delle vulnerabilità esterne al sistema: relative al modo individuate e definizione del piano delle azioni correttive (remediation plan); ⮚ produzione di reportistica di sintesi (executive summary) e di dettaglio (technical report) sulle analisi eseguite e rappresentazione delle informazioni qualitative e dimensionali sugli applicativi analizzati, con indicazioni sulle possibili ottimizzazioni da apportare. Dal punto di vista tecnico, nel caso in cui una organizzazione si connette a Internet il servizio utilizzi il codice sorgente, dovrà prevedere almeno: ⮚ compatibilità con i principali linguaggi e ad altri sistemi esterni. Include serverframework di sviluppo largamente diffusi (tra cui almeno .NET, hostPHP, dispositivi e servizi di reteC/C++, Java, J2EE, ASP, Swift, Python); ⮚ vulnerabilità delle applicazioni web e mobile: che deriverebbero da pratiche non sicure nella esecuzione di un’applicazione, di un sito web, di un APP. ⮚ vulnerabilità delle reti wireless: che permetterebbero l’accesso a dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione accesso e i dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione. ⮚ vulnerabilità delle API: relative al corretto funzionamento delle logiche applicative soprattutto per quanto riguarda le meccaniche di autenticazione e autorizzazione. ⮚ vulnerabilità degli IoT: relative al corretto funzionamento di tali infrastrutture allo scopo di estrarre informazioni o comprometterne il funzionamento. ⮚ vulnerabilità dei dati sensibili dovute ad un attacco di phising (Phishing): relative alla valutazione della suscettibilità dei dipendenti agli attacchi di “ingegneria sociale”. Le vulnerabilità possono quindi riguardare sistemi operativi, servizi, configurazioni, server, endpoint, applicazioni Web, reti wireless, dispositivi di rete, dispositivi mobili. Il servizio di “Penetration Testing” potrà essere svolto dal Fornitore mediante l’adozione di tecnologie e strumenti automatici dovrà prevedere, senza oneri aggiuntivi per l’Amministrazione. Il fornitore dovrà svolgere il servizio di “Penetration testing” mediante , l’adozione di metodologie strumenti e standard la presenza di mercato di riferimento quali: ⮚ OWASP Testing Guiderisorse professionali con competenze specifiche. Nell’esecuzione del servizio il Fornitore dovrà operare in coerenza con le previsioni indicate nelle Linee Guida Agid; ⮚ OSSTMM; ⮚ Penetration Testing Execution Standard. Di seguito in particolare si citano le fasi che il servizio di “penetration testing” dovrà prevedere sono almeno le seguenti fasi:Linee guida per lo sviluppo del software sicuro nella pubblica amministrazione (allegati tecnici 1,2, 3 e 4).

Requisiti tecnico-funzionali del servizio. Il servizio di “Penetration testing” dovrà fornire Protezione endpoint consente alle Amministrazioni di proteggere i dispositivi collegati alla rete aziendale (ad es. pc desktop. laptop, smartphone, tablet) dall’accesso non autorizzato o dall’esecuzione di software dannoso. La protezione degli endpoint garantisce, inoltre, che i dispositivi raggiungano un processo operativo livello di analisi sicurezza definito e valutazione dei punti deboli relativi ad una infrastruttura ITsiano conformi ai requisiti di conformità dell’Amministrazione. Il serviziofornitore, condotto su più fasi nell’ambito del servizio di Protezione endpoint, dovrà garantire la disponibilità per l’Amministrazione almeno delle seguenti funzionalità: ⮚ protezione dei dispositivi mediante sistemi antimalware (antivirus, antispam), impedendo lo sfruttamento delle carenze di sicurezza e mediante l’adozione l’accesso non autorizzato; ⮚ Ispezione efficace del traffico https. Blocco dell’accesso a siti potenzialmente ma levoli e controllo delle applicazioni mobile per evitare attivazioni fraudolente di adeguati strumentiActive x, si configura nella simulazione Java Script ed eseguibili, rilevando e filtrando il traffico internet dannoso in tempo reale; ⮚ conformità agli standard e quindi la possibilità di verificare se s iano applicate le regole previste dalle policy di sicurezza nel dispositivo connesso alla rete dell’Amministrazione, come ad es. utilizzo di un attacco informatico al sistema da parte operativo approvato, installazione di una VPN o l’esecuzione di un utente malintenzionato al fine software antivirus aggiornato; ⮚ monitoraggio continuo delle minacce avanzate e protezione da malware basati su file e senza file, supportando l’identificazione degli attacchi in fase iniziale e la risposta rapida ad un’ampia gamma di rilevare la presenza minacce (Endpoint Detection and Response – EDR); ⮚ controllo dell’uso dei dispositivi USB e di eventuali falle e vulnerabilità al suo interno. Verranno fornite il maggior numero di informazioni sulle vulnerabilità che hanno permesso l'accesso altri device portatili prevedendo l’utilizzo non autorizzato al sistema con una stima chiara sulle capacità di difesa e sul livello periferiche di penetrazione raggiuntoarchiviazione (ad es. A titolo esemplificativo vengono pendrive, hard-disk esterni) ed attivando il controllo ed il monitoraggio di seguito indicate tutte le eventuali vulnerabilità utilizzabili a scopi malevoli: ⮚ vulnerabilità interne al sistema: che permetterebbero l’accesso sia porte di comunicazione (ad utenti autorizzati che non autorizzaties. USB, SATA, WI-FI); ⮚ vulnerabilità esterne al sistema: relative al modo in cui una organizzazione si connette a Internet e ad altri sistemi esterni. Include serverprevenzione della perdita di dati tramite USB, hostemail, applicazioni SaaS, Web, dispositivi mobili e servizi di retearchiviazione nel cloud; ⮚ vulnerabilità delle applicazioni web e mobile: che deriverebbero da pratiche non sicure nella esecuzione di un’applicazione, di un sito web, di un APP. ⮚ vulnerabilità delle reti wireless: che permetterebbero l’accesso a dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione accesso e i dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione. ⮚ vulnerabilità delle API: relative al corretto funzionamento delle logiche applicative soprattutto crittografia dei file basata sulle policy aziendali per quanto riguarda le meccaniche di autenticazione e autorizzazione. ⮚ vulnerabilità degli IoT: relative al corretto funzionamento di tali infrastrutture allo scopo di estrarre informazioni o comprometterne il funzionamento. ⮚ vulnerabilità la protezione dei dati sensibili dovute ad un attacco di phising (Phishing): relative alla valutazione della suscettibilità dei dipendenti agli attacchi di “ingegneria sociale”. Le vulnerabilità possono quindi riguardare sistemi operativi, servizi, configurazioni, server, endpoint, applicazioni Web, reti wireless, dispositivi di rete, dispositivi mobili. Il servizio di “Penetration Testing” potrà essere svolto dal Fornitore mediante l’adozione di tecnologie e strumenti automatici senza oneri aggiuntivi per l’Amministrazione. Il fornitore dovrà svolgere il servizio di “Penetration testing” mediante l’adozione di metodologie e standard di mercato di riferimento quali: ⮚ OWASP Testing Guidesensibili; ⮚ OSSTMM; ⮚ Penetration Testing Execution Standard. Di seguito le fasi che il trasmissione di eventi e log alla funzionalità di SIEM del servizio SOC oggetto di “penetration testing” dovrà prevedere sono almeno le seguenti fasi:fornitura o ad altro strumento di raccolta log, ove disponibile, dell’Amministrazione.

Requisiti tecnico-funzionali del servizio. Il servizio di “Penetration testingSecurity Operation Center” (SOC) è il centro da cui vengono forniti i servizi alle Amministrazioni servizi mirati a garantire la corretta operatività dei sistemi attraverso la prevenzione, gestione, risoluzione di qualsiasi criticità di sicurezza che possa degradare il servizio all’utenza. La sua finalità principale è di ges tione e monitoraggio dei servizi di sicurezza oggetto di fornitura e, in aggiunta, ricevere ed analizzare ad esempio la reportistica e di log dando anche la giusta priorità ai processi di risoluzione e/o mitigazione delle minacce. Il Fornitore, nell’ambito del servizio “Security Operation Center” dovrà fornire alle Amministrazioni un processo operativo garantire all’Amministrazione almeno la disponibilità delle seguenti funzionalità base / strumenti a supporto: ⮚ la capacità di analisi identificazione, gestione, mitigazione e valutazione dei punti deboli relativi ad una infrastruttura IT. Il serviziorisoluzione degli attacchi alla sicurezza di sistemi dell’Amministrazione; ⮚ la centralizzazione di tutte le attività di gestione delle funzionalità di sicurezza legate al Sistema Informativo (rete, condotto su più fasi sistemi, dati ed applicazioni); ⮚ il monitoraggio in tempo reale dell’infrastruttura IT e mediante l’adozione di adeguati strumenti, si configura nella simulazione di un attacco informatico al sistema da parte di un utente malintenzionato Sicurezza al fine di rilevare individuare tempestivamente tentativi di intrusione, di attacco o di minaccia dei sistemi; ⮚ la raccolta centralizzata e attraverso canali cifrati (SSL) dei log e degli eventi generati da applicazioni e sistemi in rete (Security information Event managent - SIEM), anche da sistemi di sicurezza di tipo “on-site” gestiti dell’Amministrazione (ad esempio Firewall); ⮚ la disponibilità di un Console di gestione / Portale dei Servizi di Sicurezza per effettuare ad es. la gestione delle configurazioni di policy o per effettuare nuove richieste di servizi; ⮚ interazione con la piattaforma di trouble ticket del Centro servizi per la gestione delle richieste e la definizione degli alert e report; ⮚ la capacità di correlazione tra eventi diversi raccolti dal SIEM, integrando ed analizzando eventi provenienti da fonti diverse e consentendo, in aggiunta a regole predefinite, la creazione di regole personalizzate; ⮚ la disponibilità di un cruscotto (dashboard) che fornisca agli analisti, in tempo reale, una rappresentazione della situazione dei sistemi di sicurezza categorizzando per tipo di dispositivo e di dato, e la presenza di eventuali falle eventi anomali; ⮚ il supporto operativo e vulnerabilità di analisi per la rilevazione di codici malevoli al suo interno. Verranno fornite il maggior numero fine di informazioni sulle vulnerabilità che hanno permesso l'accesso non autorizzato al sistema con una stima chiara sulle capacità identificare, insieme all’eventuale supporto specialistico, le corrette politiche di difesa e sul livello prevenzione, concorrendo all’indagine per l’individuazione di penetrazione raggiunto. A titolo esemplificativo vengono di seguito indicate le eventuali vulnerabilità utilizzabili a scopi comportamenti anomali e malevoli: ⮚ vulnerabilità interne al sistema: che permetterebbero l’accesso sia ad utenti autorizzati che non autorizzati; ⮚ vulnerabilità esterne al sistema: relative al modo in cui una organizzazione si connette a Internet e ad altri sistemi esterni. Include server, host, dispositivi e servizi la produzione di rete; ⮚ vulnerabilità delle applicazioni web e mobile: che deriverebbero da pratiche non sicure nella esecuzione report periodici di un’applicazionesintesi, di un sito webincident-report di dettaglio ed istruzioni operative per consentire analisi degli incident, di un APP. ⮚ vulnerabilità delle reti wireless: che permetterebbero l’accesso a dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione accesso contromisure adottate e i dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione. ⮚ vulnerabilità delle API: relative al corretto funzionamento delle logiche applicative soprattutto per quanto riguarda le meccaniche di autenticazione e autorizzazione. ⮚ vulnerabilità degli IoT: relative al corretto funzionamento di tali infrastrutture allo scopo di estrarre informazioni o comprometterne il funzionamento. ⮚ vulnerabilità dei dati sensibili dovute ad un attacco di phising (Phishing): relative alla valutazione della suscettibilità dei dipendenti agli attacchi di “ingegneria sociale”. Le vulnerabilità possono quindi riguardare sistemi operativi, servizi, configurazioni, server, endpoint, applicazioni Web, reti wireless, dispositivi di rete, dispositivi mobili. Il servizio di “Penetration Testing” potrà essere svolto dal Fornitore mediante l’adozione di tecnologie e strumenti automatici senza oneri aggiuntivi per l’Amministrazione. Il fornitore dovrà svolgere il servizio di “Penetration testing” mediante l’adozione di metodologie e standard di mercato di riferimento quali: ⮚ OWASP Testing Guide; ⮚ OSSTMM; ⮚ Penetration Testing Execution Standard. Di seguito le fasi che il servizio di “penetration testing” dovrà prevedere sono almeno le seguenti fasi:procedure operative.

Requisiti tecnico-funzionali del servizio. Il servizio di “Penetration testing” dovrà fornire Protezione endpoint consente alle Amministrazioni di proteggere i dispositivi collegati alla rete aziendale (ad es. pc desktop. laptop, smartphone, tablet) dall’accesso non autorizzato o dall’esecuzione di software dannoso. La protezione degli endpoint garantisce, inoltre, che i dispositivi raggiungano un processo operativo livello di analisi sicurezza definito e valutazione dei punti deboli relativi ad una infrastruttura ITsiano conformi ai requisiti di conformità dell’Amministrazione. Il serviziofornitore, condotto su più fasi nell’ambito del servizio di Protezione endpoint, dovrà garantire la disponibilità per l’Amministrazione almeno delle seguenti funzionalità: ⮚ protezione dei dispositivi mediante sistemi antimalware (antivirus, antispam), impedendo lo sfruttamento delle carenze di sicurezza e mediante l’adozione l’accesso non autorizzato; ⮚ Ispezione efficace del traffico https. Blocco dell’accesso a siti potenzialmente malevoli e controllo delle applicazioni mobile per evitare attivazioni fraudolente di adeguati strumentiActive x, si configura nella simulazione Java Script ed eseguibili, rilevando e filtrando il traffico internet dannoso in tempo reale; ⮚ conformità agli standard e quindi la possibilità di verificare se siano applicate le regole previste dalle policy di sicurezza nel dispositivo connesso alla rete dell’Amministrazione, come ad es. utilizzo di un attacco informatico al sistema da parte operativo approvato, installazione di una VPN o l’esecuzione di un utente malintenzionato al fine software antivirus aggiornato; ⮚ monitoraggio continuo delle minacce avanzate e protezione da malware basati su file e senza file, supportando l’identificazione degli attacchi in fase iniziale e la risposta rapida ad un’ampia gamma di rilevare la presenza minacce (Endpoint Detection and Response – EDR); ⮚ controllo dell’uso dei dispositivi USB e di eventuali falle e vulnerabilità al suo interno. Verranno fornite il maggior numero di informazioni sulle vulnerabilità che hanno permesso l'accesso altri device portatili prevedendo l’utilizzo non autorizzato al sistema con una stima chiara sulle capacità di difesa e sul livello periferiche di penetrazione raggiuntoarchiviazione (ad es. A titolo esemplificativo vengono pendrive, hard-disk esterni) ed attivando il controllo ed il monitoraggio di seguito indicate tutte le eventuali vulnerabilità utilizzabili a scopi malevoli: ⮚ vulnerabilità interne al sistema: che permetterebbero l’accesso sia porte di comunicazione (ad utenti autorizzati che non autorizzaties. USB, SATA, WI-FI); ⮚ vulnerabilità esterne al sistema: relative al modo in cui una organizzazione si connette a Internet e ad altri sistemi esterni. Include serverprevenzione della perdita di dati tramite USB, hostemail, applicazioni SaaS, Web, dispositivi mobili e servizi di retearchiviazione nel cloud; ⮚ vulnerabilità delle applicazioni web e mobile: che deriverebbero da pratiche non sicure nella esecuzione di un’applicazione, di un sito web, di un APP. ⮚ vulnerabilità delle reti wireless: che permetterebbero l’accesso a dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione accesso e i dispositivi non autorizzati che fanno parte dell’ambiente protetto dell’organizzazione. ⮚ vulnerabilità delle API: relative al corretto funzionamento delle logiche applicative soprattutto crittografia dei file basata sulle policy aziendali per quanto riguarda le meccaniche di autenticazione e autorizzazione. ⮚ vulnerabilità degli IoT: relative al corretto funzionamento di tali infrastrutture allo scopo di estrarre informazioni o comprometterne il funzionamento. ⮚ vulnerabilità la protezione dei dati sensibili dovute ad un attacco di phising (Phishing): relative alla valutazione della suscettibilità dei dipendenti agli attacchi di “ingegneria sociale”. Le vulnerabilità possono quindi riguardare sistemi operativi, servizi, configurazioni, server, endpoint, applicazioni Web, reti wireless, dispositivi di rete, dispositivi mobili. Il servizio di “Penetration Testing” potrà essere svolto dal Fornitore mediante l’adozione di tecnologie e strumenti automatici senza oneri aggiuntivi per l’Amministrazione. Il fornitore dovrà svolgere il servizio di “Penetration testing” mediante l’adozione di metodologie e standard di mercato di riferimento quali: ⮚ OWASP Testing Guidesensibili; ⮚ OSSTMM; ⮚ Penetration Testing Execution Standard. Di seguito le fasi che il trasmissione di eventi e log alla funzionalità di SIEM del servizio SOC oggetto di “penetration testing” dovrà prevedere sono almeno le seguenti fasi:fornitura o ad altro strumento di raccolta log, ove disponibile, dell’Amministrazione.