Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 1 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Lavori di realizzazione di un sistema integrato di videocontrollo
territoriale costituito da un sottosistema di videosorveglianza
delle zone interessate e uno di riconoscimento automatico delle
targhe dei veicoli in transito.
Progetto Vi.So.Re. Trevigiano
Security Target
Sottosistema Lettura Targhe (SLT)
Versione 1.0
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 2 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Riepilogo delle modifiche
N.
Version
e
Stato Data Redatto
Approvato
Tipo di modifica
1 1.0 Rilasciato 21/11/2013 A.Mennini A.Hummer Prima Versione del documento
2 2.0 Rilasciato 28/02/2015 A.Mennini A.Hummer
Ristrutturazione completa del
documento
3 2.1 Rilasciato 14/03/2015 A.Mennini A.Hummer
Revisione cap. 2 e cap. 7 per dare
una visione più chiara e
approfondita dell’ODV
4 2.2 Rilasciato 19/08/2015 A.Mennini A.Hummer Revisione a seguito ROA
5 2.3 Rilasciato 30/09/2015 A.Mennini A.Hummer Revisione finale
Tabella 1 - Revisioni del documento
Riferimento per l’amministrazione di stato e versione:
Stato:
Elaborato (“Processed”) il documento è in corso di elaborazione
Rilasciato (“Released”) il documento è stato verificato e rilasciato dal controllo qualità; può essere
modificato solo se viene aggiornato il numero di versione.
Versioni:
Presentano due fasi. I documenti accettati ricevono il successivo numero intero di versione.
00-01, 00-02 ecc. versioni non rilasciate, con stato “Elaborato”
01 prima versione rilasciata con stato “Rilasciato”
01-01, 01-02 ecc. versioni che integrano la versione 01-00 e hanno stato “Elaborato”
02 seconda versione rilasciata con stato “Rilasciato”
Copyright
This document may be reproduced or distributed in its entirety, but the copying of only part is strictly
forbidden without the express prior written permission of Kapsch TrafficCom s.r.l.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 3 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Sommario
1. Premessa.................................................................................................................................................. 5
1.1 Obiettivi del documento.................................................................................................................... 5
1.2 Struttura del documento................................................................................................................... 5
1.3 Acronimi............................................................................................................................................ 5
1.4 Riferimenti ........................................................................................................................................ 6
2. Introduzione al security target (ASE_INT) ................................................................................................ 7
2.1 Identificazione del Security Target................................................................................................... 7
2.2 Identificazione dell’ODV ................................................................................................................... 7
2.3 Panoramica dell’ODV....................................................................................................................... 7
2.4 Descrizione dell’ODV ....................................................................................................................... 8
2.4.1 Ambito fisico................................................................................................................................. 9
2.4.2 Ambito logico.............................................................................................................................. 15
2.5 Confini ............................................................................................................................................ 16
2.6 Ruoli Utente.................................................................................................................................... 16
2.7 Funzioni di sicurezza dell’ODV ...................................................................................................... 18
3. Dichiarazione di Conformita’ (ASE_CCL) ............................................................................................... 19
4. Obiettivi di Sicurezza (ASE_OBJ)........................................................................................................... 20
4.1. Obiettivi di Sicurezza per l’Ambiente Operativo............................................................................. 20
5. Definizione di Componenti Estese (ASE_ECD)...................................................................................... 21
6. Requisiti di Sicurezza (ASE_REQ) ......................................................................................................... 22
6.1. Generalita’ ...................................................................................................................................... 22
6.2. Convenzioni.................................................................................................................................... 22
6.3. Requisiti Funzionali di Sicurezza ................................................................................................... 22
6.4. Dettaglio dei Requisiti Funzionali ................................................................................................... 23
6.5. Requisiti di Garanzia ...................................................................................................................... 31
6.6. Analisi delle Dipendenze................................................................................................................ 34
7. Specifiche Sommarie (ASE_TSS) .......................................................................................................... 37
7.1. Riepilogo delle Funzioni di Sicurezza ............................................................................................ 37
7.2. ODV_IDAU – Identification and Authentication.............................................................................. 37
7.3. ODV_AC – Access Control ............................................................................................................ 38
7.4. ODV_AUD - Auditing...................................................................................................................... 38
7.5. ODV_MGMT - Management .......................................................................................................... 39
7.6. ODV_DP – Data Protection............................................................................................................ 39
7.7. Tabella di Sintesi............................................................................................................................ 40
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 4 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Indice delle tabelle
Tabella 1 - Revisioni del documento ................................................................................................................. 2
Tabella 2 – Acronimi.......................................................................................................................................... 6
Tabella 3 - Funzioni di sicurezza dell'ODV...................................................................................................... 18
Tabella 4 - Obiettivi di sicurezza per l’ambiente.............................................................................................. 20
Tabella 5 - Requisiti Funzionali di Sicurezza dell’ODV ................................................................................... 23
Tabella 6 - Componenti di Controllo Accessi................................................................................................... 26
Tabella 7 - Security Assurance Requirements ................................................................................................ 31
Tabella 8 - Verifica delle dipendenze .............................................................................................................. 36
Tabella 9 - Sintesi dei SFR soddisfatti dalle funzioni dell’ODV ....................................................................... 41
Indice delle figure
Figura 1 - Ambito Progetto Vi.So.Re ................................................................................................................. 8
Figura 2 - Schema logico sottosistema SLT.................................................................................................... 10
Figura 3 - Architettura complessiva ................................................................................................................. 14
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 5 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
1. PREMESSA
1.1 OBIETTIVI DEL DOCUMENTO
Questo Security Target (ST) descrive gli obiettivi di sicurezza, i requisiti e le motivazioni del “Sottosistema di
Lettura Targhe (SLT) Versione 1.0” (ODV) del progetto Vi.So.Re. Trevigiano, progettato e realizzato dal RTI
Kapsch TrafficCom s.r.l. con Infracom Italia S.p.A. (nel seguito anche semplicemente RTI). Il committente della
valutazione è Kapsch TrafficCom s.r.l..
1.2 STRUTTURA DEL DOCUMENTO
Il Security Target è redatto in osservanza di quanto indicato nei CC Part.1 Version 3.1 Revision 4 relativamente
ad un “Low Assurance Security Target” e contiene le seguenti sezioni:
 Panoramica dell’ODV [Rif. § 2.3]: questa sezione fornisce una visione di insieme dell’ODV e di come si
colloca nell’ambito del progetto Vi.So.Re. Trevigiano.
 Descrizione dell’ODV [Rif. § 2.34]: questa sezione fornisce una descrizione dell’ODV, ne fornisce le
caratteristiche e ne definisce l’ambito.
 Dichiarazione di Conformità [Rif. § 3]: questa sezione presenta le conformità con in CC.
 Obiettivi di sicurezza [Rif. § 4]: questa sezione descrive in maniera dettagliata gli obiettivi di sicurezza
dell’ambiente operativo dell’ODV.
 Definizione di Componenti Estese [Rif. § 5]: Questa sezione definisce e giustifica l’utilizzo di
componenti estese.
 Requisiti di sicurezza [Rif. § 6]: questa sezione definisce i Security Functional Requirements (SFR) ed
i Security Assurance Requirements (SAR) per l’ODV.
 Specifiche sommarie [Rif. § 7]: questa sezione descrive le funzioni di sicurezza dell’ODV che soddisfano
i requisiti di sicurezza.
1.3 ACRONIMI
ACL Access Control List
CC Common Criteria
EAL Evaluation Assurance Level
IT Information Technology
ODV Oggetto Della Valutazione
PC Personal Computer
PP Protection Profile
RTI RTI Kapsch TrafficCom s.r.l. con Infracom Italia S.p.A.
SAN Storage Area Network
SAR Security Assurance Requirement
SCE Sistema Centrale di Elaborazione
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 6 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
SCNTT Sistema Centralizzato Nazionale Targhe e Transiti
SD Secure Digital
SF Security Function
SFP Security Function Policy
SFR Security Functional Requirement
SLT Sottosistema di Lettura Targhe
SNV Sottosistema Network Vi.So.Re.
ST Security Target
SVC Sottosistema Videosorveglianza Comunale
TOE Target Of Evaluation
TSF TOE Security Function
TSFI TSF Interface
Tabella 2 – Acronimi
1.4 RIFERIMENTI
[RF1] Capitolato speciale di appalto Progetto Vi.So.Re Trevigiano
[RF2] Progetto Vi.So.Re Trevigiano Relazione tecnica
[RF3] Progetto esecutivo
[RF4] DL 196/2003 e successive modificazioni
[RF5] Provvedimento in materia di videosorveglianza - 8 aprile 2010 (Gazzetta Ufficiale n. 99 del 29 aprile
2010)
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 7 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
2. INTRODUZIONE AL SECURITY TARGET (ASE_INT)
2.1 IDENTIFICAZIONE DEL SECURITY TARGET
Titolo: Security Target Sottosistema SLT v. 2.3
Data: 30/09/2015
Autore: Andrea Mennini
2.2 IDENTIFICAZIONE DELL’ODV
Nome del prodotto: Sottosistema Lettura Targhe SLT v.1.0 (nel seguito per brevità anche solo SLT)
Sviluppatore: Kapsch TrafficCom S.r.l.
2.3 PANORAMICA DELL’ODV
L’ODV è un Sottosistema di Lettura Targhe operante lungo i principali nodi stradali nell’ambito di 12 comuni
iniziali della provincia di Treviso e avente la finalità di effettuare la lettura delle targhe e rilevare l’immagine di
contesto dei veicoli in transito così da consentire: la segnalazione del transito alle forze di Polizia dello Stato
territoriali e al SCNTT. L’ODV costituisce una parte del più ampio Progetto Vi.So.Re. Trevigiano. L’ODV
prevede un certo numero di telecamere installate presso i principali nodi stradali dei comuni interessati,
collegate con posti di visualizzazione/controllo e il sistema centrale di elaborazione (SCE) mediante il
sottosistema di comunicazione SNV. L’ODV garantisce la riservatezza dei dati mediante la profilazione degli
utenti, impedendo ad utenti non autorizzati di accedere ai dati raccolti dalle telecamere ed acceduti tramite il
sottosistema SNV dai siti di visualizzazione/controllo. Presso i siti di visualizzazione/controllo l’ODV permette
agli utenti autorizzati, 24 ore su 24, un immediato accesso a SLT per la visualizzazione delle immagini acquisite
dalle telecamere installate presso i siti identificati nei minimo 12 comuni iniziali interessati. L’ODV è un Sistema
di lettura targhe costituito da un insieme omogeneo di componenti hardware e software che integrate tra di
loro, e unitamente al proprio ambiente operativo, si prefiggono l'obiettivo di rispondere ai requisiti ed alle
funzioni operative previste nel Capitolato Speciale di Appalto Progetto Vi.So.Re. Trevigiano [RF1].
AMBIENTE OPERATIVO PROGETTO VI.SO.RE. Trevigiano
Nella figura seguente viene presentato lo schema che mostra l’ambiente operativo complessivo del progetto
Vi.So.Re. Trevigiano all’interno del quale l’ODV agisce. In particolare si identificano i tre diversi sottosistemi
che costituiscono il progetto Vi.So.Re Trevigiano:
 Il sottosistema SLT, qui descritto dedicato alla lettura delle targhe
 Il sottosistema SVC, dedicato alla Videosorveglianza Comunale;
 Il sottosistema SNV, adibito all’infrastruttura dedicata di collegamento che garantisce la cifratura e la
separazione dei flussi dati in transito tra tutti i sistemi periferici e quelli centrali.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 8 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Il sottosistema SNV garantisce il collegamento sicuro tra le diverse componenti dell’ODV.
Figura 1 - Ambito Progetto Vi.So.Re
2.4 DESCRIZIONE DELL’ODV
Gli obiettivi del SLT sono quelli di effettuare la lettura automatica delle targhe e rilevare l’immagine di contesto
dei veicoli in transito lungo i principali nodi stradali delle zone interessate per consentire la segnalazione del
transito dei veicoli al SCNTT, in particolare:
 invio al SCNTT della foto in B/N della targa e dei metadati collegati (numero targa, data e ora, etc.) di
tutti i mezzi in transito,
 invio al SCNTT per le targhe appartenenti alle categorie:
o A1 (lista veicoli privi di assicurazione)
o A2 (lista veicoli privi di revisione)
o C (lista veicoli segnalati per furto ed altro),
oltre alle informazioni di cui al primo punto anche della foto a colori del veicolo.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 9 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
2.4.1 AMBITO FISICO
Il SLT si articola in quattro componenti principali di cui le prime due costituiscono l’ambito dell’ODV, il
sottosistema SNV rientra nell’ambiente operativo, mentre i Sistemi Esterni sono interfacciati dall’ODV ma non
fanno parte dell’ambiente operativo:
 Sistemi su strada
Dispositivi, appositamente progettati, che integrano due telecamere per la rilevazione e lettura targhe
e la rilevazione dell’immagine di contesto associata alla targa (foto del veicolo), in grado di analizzare,
processare e inviare in tempo reale le informazioni rilevate (immagine di contesto a colori, immagine
B/N della targa e relativi metadati). Questi dispositivi integrano al loro interno una memoria SD che
viene utilizzata in caso di assenza di collegamento per la memorizzazione cifrata AES128 temporanea
delle informazioni rilevate (immagine di contesto a colori, immagine B/N della targa e relativi metadati).
 Sistema centrale di elaborazione
Tutti i moduli applicativi del SLT installati presso la Stazione centrale di controllo della Questura di
Treviso ospitato in ambiente protetto.
 Sottosistema SNV per la comunicazione tra i Sistemi su Strada, il sistema centrale di elaborazione e
il SCNTT.
 Sistemi Esterni e infrastrutture hardware d’ambiente
Client operazionali installati presso le Stazioni Operative degli organi di Polizia; server centrali ospitanti
il sistema centrale di elaborazione; SCNTT.
La figura seguente illustra lo schema logico complessivo del sottosistema.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 10 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Figura 2 - Schema logico sottosistema SLT
2.4.1.1 Componenti dell’ODV
Sistema su strada, si compone delle seguenti componenti:
Numero iniziale di 79 Telecamere Tattile Vega 2HD - TOS, con le seguenti caratteristiche tecniche:
• Acquisizione (frames al secondo) 75
• Camera di contesto a colori
• Massima velocità dei veicoli 250 km/h
• Camera di lettura targhe Sensore CMOS 2560x2048 @ 75 fps
• Camera di contesto Sensore CMOS 2560x2048
• una scheda SD interna non direttamente accessibile per la conservazione delle immagini in caso di
attività in modalità stand alone;
• Illuminatore IR 6 LED IR, alta potenza, 850 nm
• Ottiche Obiettivo attacco C
• Ingressi digitali 1 ingresso optoisolato
• Uscite digitali 1 uscita relè 1 uscita strobe
• Ethernet 10/100 Mbps
• Porta seriale RS485
• Distanza varco Distanza: da 12 fino a 25m
• Larghezza varco: fino a 7.5m
• Temperatura operativa da -20 °C a +55 °C
• Grado di protezione IP IP66
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 11 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
• Alimentazione 24 VDC +/- 10%, 16 W
Ogni sistema su strada è dotato di specifico software integrato con le seguenti caratteristiche:
• Componente elaborativa locale dell’immagine B/N della targa dedicata all’OCR della stessa;
• Componente elaborativa locale per le funzioni di hash (SHA1), cifratura (AES 128) e firma (DSA);
• Configurazione e monitoraggio da browser Web
Sistema Centrale di Elaborazione (SCE) dell’ODV si compone dei seguenti moduli software applicativi:
 Modulo CPS
Il modulo CPS è un concentratore dei dati di transito e diagnostica provenienti dalle telecamere del
sistema. L’architettura è modulare e sono previsti una serie di moduli CPS ognuno dei quali concentra
i dati di un gruppo di telecamere. Ciò rende il sistema facilmente scalabile aggiungendo telecamere e
moduli CPS opportunamente dimensionati per garantire un parallelismo di acquisizione dati sufficiente
a gestire la mole di dati raccolta dal sistema. Il modulo CPS è realizzato in linguaggio C++ e fa uso
delle librerie Chilkat.
 Modulo DBINSERT
Questo modulo si occupa della effettiva memorizzazione sul database centrale dei dati di transito
acquisiti dai moduli CPS. Possono essere presenti più moduli DBInsert in modo da garantire un
parallelismo del flusso dati verso il database centrale sufficiente a gestire la mole di dati in ingresso.
 Modulo – CORE GESTIONALE
Questo modulo rappresenta il core dell’applicazione web centrale, realizzata in tecnologia Java EE e
installata presso la Stazione di Controllo (sala apparati) della Questura di Treviso.
 Modulo – CLIENT OPERAZIONALE
Anche questo modulo fa parte dell’applicazione web centrale, realizzata in tecnologia Java EE e
installata presso la Stazione di Controllo (sala apparati) della Questura di Treviso, e ne rappresenta,
la parte utilizzata dagli utenti appartenenti ai ruoli: Amministratore e Operatore.
 Modulo – SUPERVISORE
Anche questo modulo fa parte dell’applicazione web centrale, realizzata in tecnologia Java EE e
installata presso la Stazione di Controllo (sala apparati) della Questura di Treviso, e ne rappresenta
la parte utilizzata dagli utenti appartenenti al ruolo Super-utente
 Modulo – CONFIGURATORE
Anche questo modulo fa parte dell’applicazione web centrale, realizzata in tecnologia Java EE e
installata presso la Stazione di Controllo (sala apparati) della Questura di Treviso, e ne rappresenta
la parte direttamente utilizzata dagli utenti appartenenti ai ruoli: Amministratore e Manutentore.
 Modulo - INTERFACCIA CON SCNTT
Questo modulo è anch’esso realizzato in tecnologia Java EE e risiede presso la Stazione di Controllo
(sala apparati) della Questura di Treviso, ma non fa parte dell’applicazione web centrale: costituisce
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 12 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
invece un’applicazione separata funzionante in modalità batch e senza interazioni con gli operatori
umani.
2.4.1.2 Ambiente operativo dell’ODV
L’ambiente operativo dell’ODV si compone di due parti principali:
Sottosistema SNV, che garantisce le comunicazioni sicure tra le varie componenti (Sistemi su Strada, il
sistema centrale di elaborazione e il SCNTT) mediante VPN dedicate al SLT e la separazione dei flussi
dati dal SVC.
Infrastruttura hardware d’ambiente, così composta:
 RDBMS: Oracle 11g R2; all’interno del database sono archiviati i dati storici, statistici, e configurazioni
di sistema.
 Servers N. 2 host fisici ospitanti la piattaforma di virtualizzazione VMWARE su cui sono resi operativi
5 server virtuali. L’architettura adottata è completamente ridondata e, pertanto, configurata in
alta affidabilità a garanzia della continuità di servizio.
 SAN Storage Area network di tipo Enterprise connessa ai server in modalità Fibre Channel
opportunamente dimensionata per accogliere le immagini ed i dati previsti ed in grado di
supportare ampiamente il throughput richiesto.
 Switch L’interconnessione tra server ed i dispositivi di rete e sicurezza è garantita da una coppia di
switch Cisco 10/100/1000 (o equivalenti) in alta affidabilità.
 Client PC con sistema operativo Windows 7 professional 64bit, con doppia uscita video, monitor
dedicato da 21’’ e joystick proporzionale a 3 assi, di Monitor/TV 42’’ e di Ups di potenza
adeguata 30 minuti, situate nelle sale dei comandi di Polizia preposti a tale scopo.
2.4.1.3 Flusso generale dell’ODV e del suo ambiente operativo
Nel seguito del presente paragrafo vengono illustrati i due flussi principali: quello relativo alle immagini ed
informazioni correlate e quello relativo all’accesso al SLT da parte degli utenti dello stesso.
Flusso operativo delle immagini e delle informazioni correlate.
Il flusso operativo relativo all’acquisizione delle immagini parte dai sistemi su strada: dispositivi di acquisizione
delle immagini (foto) composti da un unico apparato Vega 2HD al cui interno sono assemblate le diverse
componenti già descritte al paragrafo precedente.
All’interno dei sistemi su strada sulle foto acquisite in formato RAW al passaggio di un veicolo vengono svolte
le seguenti elaborazioni locali:
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 13 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
 elaborazione dell’immagine B/N della targa e di quella a colori del veicolo per la creazione dei relativi
file in formato standard JPEG;
 elaborazione OCR dell’immagine B/N della targa per il riconoscimento dei caratteri alfanumerici
componenti la stessa;
 valorizzazione dei metadati dei due file JPEG (targa e contesto) con le informazioni di transito (data,
ora, targa, id della telecamera, etc.);
 Creazione di un messaggio unico contenente entrambi i file identificati dai relativi header
 Invio dal sistema su strada alla componente server CPS del CSE del messaggio unico mediante
l’apertura di una socket, con protocollo di comunicazione di tipo proprietario, mediante SNV (SNV
garantisce la sicurezza delle comunicazioni e la separazione dai flussi rispetto a SVC).
 In assenza di collegamento di rete il messaggio unico viene memorizzato nella memoria SD locale,
per essere poi trasmesso, alla riconnessione, con la modalità sopra indicata in maniera
completamente trasparente all’utente e senza che l’utente possa avere accesso in alcun modo alla
memoria SD.
Tutte le elaborazioni interne sopra descritte avvengono nella memoria RAM del sistema su strada.
Il modulo CPS, ricevuto il messaggio unico dal client sistema su strada:
 effettua la post elaborazione consistente nella applicazione di ulteriori e più sofisticati algoritmi sulle
immagini tra cui: OCR di secondo livello, algoritmo MMR per l’analisi del colore, algoritmo di
classificazione, algoritmo di ricerca del modello di veicolo, ed altri;
 Terminata questa post elaborazione richiama il Modulo DBInsert per la memorizzazione delle
informazioni nel data base.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 14 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Figura 3 - Architettura complessiva
Il modulo DBInsert estrae le informazioni dai metadati dei file JPEG, a cui aggiunge le altre informazioni
ottenute dal processo di post elaborazione, e inserisce il tutto unitamente alle due immagini JPEG all’interno
del database ORACLE.
Il modulo Core Gestionale SLT svolge le operazioni di:
 verifica della presenza in tempo reale, nelle liste generali (A1, A2 e C) e locali, della targa rilevata nel
transito.
 per ogni transito dialoga con il modulo di interfacciamento SCNTT per la spedizione delle immagini B/N
della targa tramite SNV al SCNTT.
 nel caso in cui la targa rilevata risulti presente in una lista qualsiasi, genera un allarme del tipo
corrispondente.
 in caso di allarme generato da corrispondenza trovata nelle liste generali dialoga con il modulo di
interfacciamento SCNTT per la spedizione dell’immagine a colori del transito corrispondente tramite
SNV al SCNTT.
 storicizza l’allarme nel database ORACLE
 allo scadere dei periodi di conservazione di 15 giorni e di 90 giorni per i veicoli di Lista C (comunque
configurabili) nel database Oracle, le registrazioni dei transiti e degli allarmi vengono cancellate.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 15 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Flusso operativo relativo all’accesso degli utenti dell’ODV
Gli utenti dell’ODV afferenti ai ruoli di seguito indicati accedono all’ODV tramite interfaccia web;
successivamente all’identificazione dell’utente, vengono assegnati il ruolo e le corrispondenti autorizzazioni
e di conseguenza vengono abilitati i moduli Client autorizzati. I possibili moduli sono: Operazionale,
Supervisore telecamere e Configuratore, questi garantiscono l’accesso alle rispettive attività connesse al
ruolo specifico. Le operazioni riguardanti la gestione degli Utenti/Ruoli ed il trattamento delle
telecamere/immagini comportano la scrittura nel file di log dell’operazione eseguita. L’utente dell’ODV per
collegarsi allo stesso deve connettersi al SNV che garantisce il collegamento di tipo sicuro. L’interfaccia per
gli utenti dell’ODV è di tipo WEB.
Ogni utente per accedere alle funzionalità del sistema deve prima superare la procedura di identificazione ed
autenticazione di SLT che richiede nome utente e password. Al primo login l’utente è obbligato a cambiare
password, poiché alla generazione dell’utente viene acceso un flag che avvisa di cambiare password al
login. Ad ogni utente quindi viene assegnata una password di primo collegamento, che deve essere
obbligatoriamente cambiata impostandone una propria con le seguenti caratteristiche minime:
a. la lunghezza minima della password deve essere composta da almeno 8 caratteri;
b. i caratteri contenuti nella password devono contenere almeno una cifra numerica, almeno un
carattere speciale (ad esempio !, @, #, $), e sia lettere minuscole che maiuscole;
c. ogni password deve essere cambiata obbligatoriamente dopo 3 mesi;
d. ogni account scade dopo 6 mesi di inutilizzo.
2.4.2 AMBITO LOGICO
Il software SLT è sviluppato su piattaforma aperta e progettata per progetti su larga scala. Grazie agli
applicativi client fornisce agli operatori tramite mappe grafiche interattive e di tipo multi livello, un eccezionale
sistema di controllo panoramico per tutto l’impianto. L’ODV include un efficiente metodo d’amministrazione
centralizzata, procedure guidate intuitive, flessibili regole di funzionamento del sistema. Queste caratteristiche
permettono di gestire con facilità la personalizzazione di un impianto di lettura targhe pur se geograficamente
esteso.
In particolare da un punto di vista della sicurezza l’ODV:
 consente una gestione selettiva delle immagini e delle telecamere dando agli amministratori la
possibilità di configurare l’accesso alle funzioni, alle telecamere ed ai dati delle targhe in base al ruolo
di ciascun utente.
 genera log relativi alle operazioni sulle telecamere e sugli utenti
 rende disponibili le immagini raccolte dalle telecamere anche nel caso di interruzione dei collegamenti,
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 16 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
 memorizza le immagini raccolte dalle telecamere, la loro visualizzazione, la loro conservazione e la
loro eventuale esportazione per prove giuridiche.
Altre funzioni del sottosistema SLT, proprie dell’ambiente operativo e descritte nel successivo par. 4,
concorrono al raggiungimento degli obiettivi prefissati.
2.5 CONFINI
Come si vede dalla figura 3, l’ODV si interfaccia con il sottosistema SNV, che realizza i collegamenti con i
sistemi su strada, con gli utenti e con il SCNTT.
In base a quanto descritto nel precedente par. 2.4 e relativi sottoparagrafi, si evince che:
 il confine fisico dell’ODV è rappresentato dal sottosistema SNV, con la precisazione che il
sottosistema SNV fa parte dell’ambiente operativo (v. par. 2.4.1.3).
 il confine logico dell’ODV è rappresentato dalle funzioni descritte nel successivo par. 2.7.
2.6 RUOLI UTENTE
SLT gestisce i seguenti ruoli utente:
 Amministratore
 Super-utente
 Operatore
 Manutentore
Gli utenti del sistema hanno accesso all’interfaccia web degli specifici moduli SCE (rif. Figura 3 - Architettura
complessiva).
Ogni utente è caratterizzato da uno e un solo profilo:
Amministratore: è il gestore dell'applicazione, e come tale controlla il corretto funzionamento dei moduli
creando le aree geografiche e i super-utenti; ha accesso soltanto alla parte di interfaccia del modulo
“Configuratore”. Questi utenti avranno i diritti (configurabili) per accedere ed usufruire delle seguenti
funzionalità dell’ODV:
 Inserimento, modifica, disabilitazione delle utenze del sistema, gestione di gruppi e ruoli assegnati ad
ogni utente.
 Configurazione di allarmi, azioni applicabili a seguito di allarmi, priorità di intervento per ogni allarme
 Gestione soglie di allarme sui flussi di traffico
 Configurazione dei tempi di conservazione dei dati
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 17 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
 Configurazione parametri dell’intero sistema e parametri di connessione per l’integrazione verso
SCNTT
Super-utente: viene definito come gestore dei dati legati a una o più aree geografiche, ha accesso soltanto
alla parte di interfaccia del modulo “Configuratore”, limitatamente alla gestione dei dati legati alle aree
geografiche e gruppi di Utenti di sua competenza. Questi utenti avranno i diritti (configurabili) per accedere ed
usufruire delle seguenti funzionalità dell’ODV:
 Gestione delle aree geografiche (Provincie, Dipartimenti, comuni, Sottoaree comunali) Anagrafica
(georeferenziata) dei varchi e corsie di ubicazione apparati di campo.
 Connessioni logiche tra gruppi di utenti, aree geografiche e varchi, per la gestione settorializzata di
transiti, allarmi, priorità di intervento, etc. per ogni Sede Operativa
 Gestione delle liste targhe (white list, hot list locali, targhe merci pericolose) con interazione eventuale
con liste di SCNTT
Manutentore: gestisce gli allarmi derivanti dai malfunzionamenti degli apparati coordinando gli interventi di
riparazione, è responsabile di una o più aree e ha accesso soltanto alla parte di interfaccia del modulo
”Supervisore”;
Operatore: ha accesso soltanto alla parte di interfaccia del modulo “Client Operazionale”. Gli utenti del sistema
utilizzatori del “Client Operazionale SLT” saranno gli Operatori delle Stazioni Operative (Sale Operative) con
diverse competenze territoriali. Questi utenti avranno i diritti (configurabili) per accedere ed usufruire delle
seguenti funzionalità dell’ODV:
 Gestione delle liste targhe locali di competenza
 Visualizzazione degli allarmi del sistema (Apparati di campo di competenza)
 Visualizzazione dei transiti con gestione evidente (colori differenti) delle differenti tipologie di allarmi
transito con possibilità di annotazione testuale su specifica segnalazione
 Avvertimento in tempo reale di allarmi su transiti segnalati su liste
 Avvertimento in tempo reale di allarmi su apparati di campo
 Visualizzazione cartografica interattiva georeferenziata di:
o Liste transiti
o Ricerca transiti per targa, intervallo date, etc..
o Elementi periferici di campo ed eventuali allarmi di malfunzionamento
o Successione cronologica dei transiti di una targa
 Azioni verso SCNTT:
o Inserimento targhe da segnalare in lista C
o Ricerche su transiti
o Prelievo dati ai fini giudiziari ed investigativi, previa autorizzazione
 Visualizzazione ed export di dati statistici, contatori, e report.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 18 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
2.7 FUNZIONI DI SICUREZZA DELL’ODV
La tabella seguente fornisce una sintetica descrizione delle funzioni di sicurezza dell’ODV.
Codice
Funzione di
sicurezza
Descrizione
ODV_IDAU Autenticazione utenti
L’ODV deve provvedere alla identificazione ed
autenticazione degli utenti, mediante funzioni di:
 controllo userid e password
 controllo della composizione delle password
 controllo di validità
 controllo di prima autenticazione
 controllo del numero dei tentativi di
autenticazione.
ODV_AC Access control
L’ODV consente agli amministratori di configurare
l’accesso alle funzioni dell’ODV stesso ed ai dati in
base al ruolo di ciascun utente.
ODV_AUD Auditing
L’ODV genera log relativi agli accessi degli utenti alle
funzioni dell’ODV, sia ai tentativi positivi sia a quelli
falliti (operazioni di autenticazione). L’ODV genera log
relativi alla gestione delle immagini inviate dalla
telecamere.
ODV_MGMT Gestione
L’ODV provvede al controllo delle seguenti operazioni:
a) Operazioni su ruoli e utenti
b) Operazioni sulle telecamere
ed all’assegnazione di un riferimento temporale
affidabile per ciascuna delle operazioni suddette.
ODV_DP Data Protection
L’ODV garantisce la disponibilità delle immagini anche
in caso di interruzione dei collegamenti fra telecamere
e Sistema Centralizzato di Controllo, mediante il
salvataggio delle stesse nella memoria SD delle
telecamere.
L’ODV provvede alla cancellazione delle immagini
registrate dopo il periodo di tempo stabilito dalle
politiche di accesso, nel rispetto della privacy.
Tabella 3 - Funzioni di sicurezza dell'ODV
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 19 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
3. DICHIARAZIONE DI CONFORMITA’ (ASE_CCL)
Il ST e il ODV sono conformi alla versione 3.1 (Revision 4) of the Common Criteria for Information Technology
Security Evaluation.
La dichiarazione di conformità si riferisce a:
Common Criteria for Information Technology Security Evaluation. Version 3.1 Rev.4 Part 1 september 2012
 Common Criteria for Information Technology Security Evaluation, Part 2: Security functional
requirements, Version 3.1 Rev. 4 september 2012
 Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance
requirements, Version 3.1 Rev. 4 september 2012
Il pacchetto di garanzia dichiarato è EAL1.
Questo ST non dichiara la conformità ad alcun Protection Profile.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 20 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
4. OBIETTIVI DI SICUREZZA (ASE_OBJ)
In linea con quanto previsto dal livello di garanzia EAL1, il paragrafo contiene definizioni concise degli obiettivi
che devono essere soddisfatti dall’ambiente a supporto dell’ODV.
4.1. OBIETTIVI DI SICUREZZA PER L’AMBIENTE OPERATIVO
Obiettivo Descrizione
OE.Admin
Gli Amministratori dell’ODV devono essere scelti tra il personale fidato e
addestrati al corretto utilizzo dell’ODV.
OE.Physical
I responsabili del sottosistema SLT devono assicurare che l’infrastruttura
tecnologica dell’ODV sia custodita in locali nei quali l’accesso è consentito
solamente al personale autorizzato.
OE.External
I responsabili del sottosistema SLT devono assicurare la protezione e
sorveglianza agli apparati posti all’esterno.
OE.Crypto
I sistemi su strada devono provvedere alla cifratura delle immagini raccolte
dalle telecamere e non immediatamente trasmesse al Sistema Centralizzato
di Controllo, con l’obiettivo di preservarne la riservatezza.
OE.Network
Il sottosistema SNV ha il compito di assicurare la connettività fra le seguenti
componenti l’ODV:
 Sistema Centrale di Elaborazione;
 Telecamere;
 Utenti dell’ODV
Il sottosistema SNV deve proteggere la trasmissione dei dati raccolti dalle
telecamere realizzando canali cifrati e separati in base alla destinazione dei
dati stessi.
OE.Policy
L’Organizzazione deve assicurare, per quanto di competenza, la conformità
alle leggi e normative in vigore sulla privacy.
OE.Time
L’ambiente operativo dell’ODV deve fornire riferimenti temporali affidabili per
le operazioni sotto il controllo dell’ODV.
Tabella 4 - Obiettivi di sicurezza per l’ambiente
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 21 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
5. DEFINIZIONE DI COMPONENTI ESTESE (ASE_ECD)
Questo ST esclude la definizione di componenti estese.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 22 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
6. REQUISITI DI SICUREZZA (ASE_REQ)
6.1. GENERALITA’
Questa sezione definisce i requisiti di sicurezza e di garanzia soddisfatti dal ODV.
Ogni requisito è stato estratto dai Common Criteria for Information Technology Security Evaluation, Part 2:
Security functional requirements, Version 3.1 Rev. 4 september 2012 e dai Common Criteria for Information
Technology Security Evaluation, Part 3: Security assurance requirements, Version 3.1 Rev. 4 september 2012.
6.2. CONVENZIONI
Assegnazione L’operazione di assegnazione consente di specificare un parametro all’interno di un
requisito. Le assegnazioni sono indicate usando un testo in grassetto all’interno di
parentesi quadre [assegnazione].
Selezione L’operazione di selezione permette di selezionare uno o più elementi da una lista. Le
selezioni sono indicate usando testo in corsivo all’interno di parentesi quadre [selezione].
Raffinamento L’operazione di raffinamento consiste nel dare un ulteriore dettaglio a un requisito. Le
operazioni di raffinamento sono indicate usando un testo in grassetto per le aggiunte e
barrando il testo da cancellare.
Iterazione L’operazione di iterazione permette di utilizzare più di una volta un componente per effettuare
operazioni diverse. Una iterazione si effettua ponendo uno slash “/” alla fine del componente
seguito da un unico nome che identifica l’iterazione.
6.3. REQUISITI FUNZIONALI DI SICUREZZA
Functional Requirements
Classes Families Description
FAU:Security Audit FAU_GEN.1 Audit data generation
FDP: User data protection
FDP_ACC.1 Subset access control
FDP_ACF.1 Security attribute based access control
FDP_ETC.1 Export of user data without security attributes
FDP_RIP.1 Subset residual information protection
FIA: Identification and
authentication
FIA_AFL.1 Authentication failure handling
FIA_ATD.1 User attribute definition
FIA_UAU.1 Timing of authentication
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 23 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Functional Requirements
FIA_SOS.1 Verification of secrets
FIA_UID.2 User identification before any action
FMT: Security Management
FMT_MSA.1 Management of security attributes
FMT_MSA.3 Static attribute initialisation
FMT_SMF.1 Specification of management functions
FMT_MTD.1 Management of TSF data
FMT_SMR.1 Security roles
FRU: Resources utilization FRU_FLT.1 Degraded fault tolerance
Tabella 5 - Requisiti Funzionali di Sicurezza dell’ODV
6.4. DETTAGLIO DEI REQUISITI FUNZIONALI
FAU_GEN.1
Hierarchical to: No other components.
FAU_GEN.1.1
The TSF shall be able to generate an audit record of the following
auditable events:
1. Start‐up and shutdown of the audit functions;
2. All auditable events for the [not specified] level of audit; and
3. [The following auditable events:
a) Modifiche nelle assegnazioni di utenti ai ruoli previsti
(funzione del ruolo amministratore)
b) User login/logout e tentativi falliti di login
c) Gestione delle immagini: registrazione, invio al SCNTT,
cancellazione
d) Gestione delle telecamere: attivazione, disattivazione
]
FAU_GEN.1.2
The TSF shall record within each audit record at least the following
information:
a) Date and time of the event, type of event, subject identity (if
applicable), and the outcome (success or failure) of the event;
and
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 24 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
FAU_GEN.1
b) For each audit event type, based on the auditable event
definitions of the functional components included in the ST
[none].
Dependencies: FPT_STM.1 Reliable time stamps
Notes:
FDP_ACC.1
Hierarchical to: No other components.
FDP_ACC.1.1 The TSF shall enforce the [SLT access control SFP] on
[
Soggetti:
a) Utenti
b) Sistemi su strada
Oggetti:
a) Immagini di transito
b) Veicoli
Operazioni:
a) Gestione immagini
]
Dependencies: FDP_ACF.1 Security attribute based access control
Notes: Le operazioni sopra indicate sono raggruppate per tipologia. Le stesse vengono
dettagliate nella Tabella 6 “Componenti di controllo accessi”.
FDP_ACF.1
Hierarchical to: No other components.
FDP_ACF.1.1 The TSF shall enforce the [SLT access control SFP] to objects
based on the following: [
Attributi dei soggetti:
Ruolo (per gli utenti): amministratore, super-utente,
manutentore, operatore
ID (per i sistemi su strada)
Attributi degli oggetti:
a) Varco (Immagini)
b) Tempo di conservazione (Immagini)
c) Targa (Veicoli)
]
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 25 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
FDP_ACF.1
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed: [La
tabella 6 “Componenti di controllo accessi” stabilisce la
relazione fra soggetti, oggetti e operazioni]
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: [none].
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on
the following additional rules: [none].
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
Notes:
COMPONENTI DI CONTROLLO ACCESSI
La tabella sottostante definisce soggetti, oggetti, operazioni e attributi, come regolati dalla SLT Access
Control SFP.
SOGGETTI ATTRIBUTI OGGETTI ATTRIBUTI OPERAZIONI
Sistemi su
strada
ID
Immagini di
transito
Varco
Il sistema su strada provvede
alla creazione del messaggio
per SCE e all’invio alla
componente server CPS del
CSE.
In assenza di collegamento di
rete il messaggio viene
memorizzato nella memoria
SD locale, per essere poi
trasmesso, alla riconnessione,
con la modalità sopra indicata.
Utenti Amministratore
Immagini di
transito
Tempo di
conservazione
L’utente amministratore può
modificare il tempo di
conservazione dei dati di
transito nel SCE
L’utente amministratore ha la
possibilità di gestire
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 26 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
COMPONENTI DI CONTROLLO ACCESSI
La tabella sottostante definisce soggetti, oggetti, operazioni e attributi, come regolati dalla SLT Access
Control SFP.
SOGGETTI ATTRIBUTI OGGETTI ATTRIBUTI OPERAZIONI
l’associazione fra i varchi e gli
operatori
Utenti Superutente
Operazioni non gestite dalle
TSF
Utenti Operatore Veicolo Targa
L’utente operatore ha la
possibilità di vedere le
immagini provenienti dai
sistemi su strada, in base alla
assegnazione dei varchi
Utenti Manutentore
Operazioni non gestite dalle
TSF
Tabella 6 - Componenti di Controllo Accessi
FDP_ETC.1
Hierarchical to: No other components.
FDP_ETC.1.1 The TSF shall enforce the [SLT access control SFP] when exporting
user data, controlled under the SFP, outside of the TOE.
FDP_ETC.1.2 The TSF shall export the user data without the user data's associated
security attributes.
Dependencies:
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
Notes: L’ODV provvede ad inviare le immagini in chiaro al SCNTT
FDP_RIP.1
Hierarchical to: No other components.
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a
resource is made unavailable upon the [deallocation of the resource
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 27 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
FDP_RIP.1
from] the following objects: [immagini conservate nel Sistema
Centrale di Elaborazione].
Dependencies: No dependencies
Notes: Tutte le immagini memorizzate nel Sistema Centrale di Elaborazione vengono cancellate
dopo un periodo di tempo di 15 giorni per i transiti e di 90 giorni per gli allarmi.
FIA_AFL.1
Hierarchical to: No other components
FIA_AFL.1.1 The TSF shall detect when [5], unsuccessful authentication attempts
occur related to [autenticazione dell’utente].
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts
has been [met], the TSF shall [bloccare l’utente].
Dependencies: FIA_UAU.1 Timing of authentication
Notes: Notes:
FIA_ATD.1
Hierarchical to: No other components
FIA_ATD.1.1 The TSF shall maintain the following list of security attributes
belonging to individual users: [
a) User ID
b) Password
c) Ruolo
d) Stato (bloccato, abilitato ad operare)
].
Dependencies: No dependencies
Notes:
FIA_UAU.1
Hierarchical to: No other components
FIA_UAU.1.1 The TSF shall allow [il cambio della password al primo accesso di
un utente] on behalf of the user to be performed before the user is
authenticated.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 28 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of that
user.
Dependencies: FIA_UID.1 Timing of identification
Notes: Ad ogni nuovo utente viene assegnata una password di default, con
l’obbligo di cambiarla al primo accesso al sistema secondo le regole
stabilite in FIA_SOS.1.
FIA_UID.2
Hierarchical to: FIA_UID.1 Timing of identification
FIA_UID.2.1 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
Dependencies: No dependencies
Notes:
FIA_SOS.1
Hierarchical to: No other components
FIA_SOS.1.1 TSF shall provide a mechanism to verify that secrets meet [la
password:
 deve avere la lunghezza minima di almeno 8 caratteri;
 i caratteri devono contenere almeno una cifra numerica,
almeno un carattere speciale (ad esempio !, @, #, $), e sia
lettere minuscole che maiuscole;
 deve essere cambiata obbligatoriamente dopo 3 mesi;
]
Dependencies: No dependencies
Notes:
FMT_MSA.1
Hierarchical to: No other components.
FMT_MSA.1.1 The TSF shall enforce the [SLT access control SFP], to restrict the
ability to [modify] the security attributes [ruoli, tempo di
conservazione delle immagini di transito] to [amministratore].
Dependencies: [FDP_ACC.1 Subset access control, or
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 29 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
FMT_MSA.1
FDP_IFC.1 Subset information flow control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Functions
Notes:
FMT_MSA.3
Hierarchical to: No other components.
FMT_MSA.3.1 The TSF shall enforce the [SLT access control SFP] to provide [
restrictive] default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2 The TSF shall allow the [amministratore] to specify alternative initial
values to override the default values when an object or information is
created.
Dependencies: FMT_MSA.1 Management of security attributes
FMT_SMR.1 Security roles
Notes: Le regole di conservazione delle immagini di transito prevedono che il loro tempo di
conservazione abbia un valore di default che stabilisce a 15 giorni la durata di
conservazione.Il “tempo di conservazione” è stato dichiarato come attributo ed il valore
imposto è di tipo restrittivo.
FMT_MTD.1
Hierarchical to: No other components.
FMT_MTD.1.1 The TSF shall restrict the ability to [unlock] the [stato] to
[amministratore].
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of Management Function
Notes:
FMT_SMF.1
Hierarchical to: No other components.
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions: [
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 30 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
FMT_SMF.1
a) Inserimento, modifica, disabilitazione delle utenze del
sistema, gestione dei ruoli assegnati ad ogni utente,
riattivazione di utenti disabilitati
b) Modifica del tempo di conservazione dei dati di transito].
Dependencies: No dependencies
Notes: Tutte le funzioni di gestione vengono realizzate tramite le interfacce fornite dal modulo
“Configuratore”.
L’inserimento di nuovi utenti comprende anche l’assegnazione di userid e password di
default.
FMT_SMR.1
Hierarchical to: No other components.
FMT_SMR.1.1 The TSF shall maintain the roles [
a) Amministratore
b) Superutente
c) Operatore
d) Manutentore
].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Dependencies: FIA_UID.1 Timing of identification
Notes:
FRU_FLT.1
Hierarchical to: No other components.
FRU_FLT.1.1 The TSF shall ensure the operation of [salvataggio delle immagini
raccolte dalle telecamere] when the following failures occur:
[interruzione della trasmissione delle immagini dalle telecamere
al Sistema Centrale di Elaborazione].
Dependencies: FPT_FLS.1 Failure with preservation of secure state
Notes: In caso di interruzione del collegamento fra le telecamere ed il Sistema Centrale di
Elaborazione, le telecamere hanno la capacità di trattenere le immagini nella propria
memoria SD, fino al ripristino del collegamento.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 31 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
6.5. REQUISITI DI GARANZIA
I requisiti di garanzia per il ODV sono quelli previsti al livello EAL1, come specificato nella Parte 3 dei Common
Criteria, senza potenziamenti.
EAL1 è stato scelto come livello di garanzia in quanto il ODV opererà in un ambiente protetto, con
amministratori competenti e con utenti specializzati e fidati. In questo contesto si assume che eventuali
attaccanti avranno un potenziale di attacco limitato, di conseguenza il livello EAL1 è appropriato per fornire la
garanzia necessaria a contrastare attacchi a limitato potenziale.
Assurance Class Assurance components
ADV: Development ADV_FSP.1Basic functional specification
AGD: Guidance documents AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
ALC: Life-cycle support ALC_CMC.1Labelling of the TOE
ALC_CMS.1TOE CM coverage
ATE: Tests ATE_IND.1Independent testing - conformance
AVA: Vulnerability assessment AVA_VAN.1Vulnerability survey
ASE: Security Target Evaluation ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.1 Security objectives
ASE_REQ.1 Stated security requirements
ASE_TSS.1 TOE summary specification
Tabella 7 - Security Assurance Requirements
ADV_FSP.1 Basic functional specification
Dependencies:
None.
Developer action elements:
ADV_FSP.1.1D The developer shall provide a functional specification.
ADV_FSP.1.2D The developer shall provide a tracing from the functional specification to the SFRs.
AGD_OPE.1 Operational user guidance
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 32 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Dependencies:
ADV_FSP.1 Basic functional specification
Developer action elements:
AGD_OPE.1.1D The developer shall provide operational user guidance.
AGD_PRE.1 Preparative procedures
Dependencies:
None.
Developer action elements:
AGD_PRE.1.1D The developer shall provide the TOE including its preparative
procedures.
ALC_CMC.1 Labeling of the TOE
Dependencies:
ALC_CMS.1 TOE CM coverage
Developer action elements:
ALC_CMC.1.1D The developer shall provide the TOE and a reference for the TOE.
ALC_CMS.1 TOE CM coverage
Dependencies:
None.
Developer action elements:
ALC_CMS.1.1D The developer shall provide a configuration list for the TOE.
ASE_INT.1 ST introduction
Dependencies:
None.
Developer action elements:
ASE_INT.1.1D The developer shall provide an ST introduction.
ASE_CCL.1 Conformance claims
Dependencies:
ASE_INT.1 ST introduction
ASE_ECD.1 Extended components definition
ASE_REQ.1 Stated security requirements
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 33 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Developer action elements:
ASE_CCL.1.1D The developer shall provide a conformance claim.
ASE_CCL.1.2D The developer shall provide a conformance claim rationale.
ASE_OBJ.1 Security objectives for the operational environment
Dependencies:
None.
Developer action elements:
ASE_OBJ.1.1D The developer shall provide a statement of security objectives.
ASE_ECD.1 Extended components definition
Dependencies:
No dependencies.
Developer action elements:
ASE_ECD.1.1D The developer shall provide a statement of security requirements.
ASE_ECD.1.2D The developer shall provide an extended components definition.
ASE_REQ.1 Stated security requirements
Dependencies:
ASE_ECD.1 Extended components definition
Developer action elements:
ASE_REQ.1.1D The developer shall provide a statement of security requirements.
ASE_REQ.1.2D The developer shall provide a security requirements rationale.
ASE_TSS.1 TOE summary specification
Dependencies:
ASE_INT.1 ST introduction
ASE_REQ.1 Stated security requirements
ADV_FSP.1 Basic functional specification
Developer action elements:
ASE_TSS.1.1D The developer shall provide a TOE summary specification.
ATE_IND.1 Independent testing - conformance
Dependencies:
ADV_FSP.1 Basic functional specification
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 34 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Developer action elements:
ATE_IND.1.1D The developer shall provide the TOE for testing.
AVA_VAN.1 Vulnerability survey
Dependencies:
ADV_FSP.1 Basic functional specification
AGD_OPE.1 Operational user guidance
AGD_PRE.1 Preparative procedures
Developer action elements:
AVA_VAN.1.1D The developer shall provide the TOE for testing.
6.6. ANALISI DELLE DIPENDENZE
La seguente Tabella 8 mostra le dipendenze richieste dai Common Criteria per ogni SFR e SAR a livello di
garanzia EAL1.
Functional
Requirements
Dipendenze richieste dai CC Dipendenze soddisfatte
SFR
FAU_GEN.1 FPT_STM.1 Reliable time stamps Nota 2
FDP_ACC.1
FDP_ACF.1 Security attribute based
access control
FDP_ACF.1 Security attribute based
access control
FDP_ACF.1
FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute
initialization
FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute
initialisation
FDP_ETC.1
FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow
control
FDP_ACC.1 Subset access control
FDP_RIP.1 None None
FIA_AFL.1 FIA_UAU.1 Timing of authentication FIA_UAU.2
FIA_ATD.1 None None
FIA_SOS.1 None None
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 35 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Functional
Requirements
Dipendenze richieste dai CC Dipendenze soddisfatte
FIA_UAU.1 FIA_UID.1 Timing of identification FIA_UID.2
FIA_UID.2 None None
FMT_MSA.1
[FDP_ACC.1 Subset access
control, or
FDP_IFC.1 Subset information flow
control]
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of
Management Functions
FDP_ACC.1 Subset access
control,
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of
Management Functions
FMT_MSA.3
FMT_MSA.1 Management of
security attributes
FMT_SMR.1 Security roles
FMT_MSA.1 Management of
security attributes
FMT_SMR.1 Security roles
FMT_SMF.1 None None
FMT_MTD.1
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of
Management Function
FMT_SMR.1 Security roles
FMT_SMF.1 Specification of
Management Function
FMT_SMR.1 FIA_UID.1 Timing of identification FIA_UID.2
FRU_FLT.1
FPT_FLS.1 Failure with preservation
of secure state
Nota 1
SAR
ADV_FSP.1 None None
AGD_OPE.1
ADV_FSP.1 Basic functional
specification
ADV_FSP.1 Basic functional
specification
AGD_PRE.1 None None
ALC_CMC.1 ALC_CMS.1 TOE CM coverage ALC_CMS.1 TOE CM coverage
ALC_CMS.1 None None
ATE_IND.1
ADV_FSP.1 Basic functional
specification
AGD_OPE.1 Operational user
guidance
AGD_PRE.1 Preparative
procedures
ADV_FSP.1 Basic functional
specification
AGD_OPE.1 Operational user
guidance
AGD_PRE.1 Preparative
procedures
AVA_VAN.1
ADV_FSP.1 Basic functional
specification
ADV_FSP.1 Basic functional
specification
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 36 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Functional
Requirements
Dipendenze richieste dai CC Dipendenze soddisfatte
AGD_OPE.1 Operational user
guidance
AGD_PRE.1 Preparative
procedures
AGD_OPE.1 Operational user
guidance
AGD_PRE.1 Preparative
procedures
Tabella 8 - Verifica delle dipendenze
Nota 1 – Nel caso in cui l’ambiente non fornisce il collegamento ad una telecamera, l’ODV si preoccupa
di salvare le immagini, ma non vengono effettuate altre funzioni per il mantenimento dello stato
sicuro in quanto non necessarie per il funzionamento del sottosistema.
Nota 2 - La dipendenza non è soddisfatta in quanto il riferimento temporale affidabile viene fornito
dall’ambiente operativo.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 37 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
7. SPECIFICHE SOMMARIE (ASE_TSS)
Questa sezione fornisce le specifiche sommarie dell’ODV, una definizione ad alto livello delle funzioni di
sicurezza che soddisfano i requisiti funzionali di sicurezza e di garanzia.
7.1. RIEPILOGO DELLE FUNZIONI DI SICUREZZA
Le funzioni di sicurezza rappresentate nel Security Target sono le seguenti:
1. ODV_IDAU – Identification and authentication
2. ODV_AC – Access Control
3. ODV_AUD - Auditing
4. ODV_MGMT - Management
5. ODV_DP – Data Protection
7.2. ODV_IDAU – IDENTIFICATION AND AUTHENTICATION
Amministratori ed utenti devono identificarsi ed autenticarsi prima di accedere alle funzioni dell’ODV.
L’ODV applica una rigorosa procedura di accesso, di seguito sintetizzata, prima di abilitare l’utente ad
operare a seguito di autenticazione positiva, in particolare la procedura:
1) Richiede le credenziali di accesso
2) Verifica la rispondenza con quanto registrato dal sistema di autenticazione
3) In caso di primo accesso da parte di un utente, obbliga al cambio della password
4) Informa l’utente in caso di esito negativo
5) Gestisce l’autorizzazione per l’accesso alle diverse funzionalità dell’applicativo
L’ODV mediante le funzioni dei moduli Client Operazionale, Supervisore e Configuratore gestisce
l’identificazione e l’autenticazione di un utente che vuole operare con SLT. I tre moduli presentano la finestra
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 38 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
di inserimento delle credenziali di accesso (utente e password) e mediante i controlli operati sulle stesse
garantiscono che:
1) Inserendo le credenziali di un utente registrato e non scaduto, l’ODV abilita ad utilizzare l’applicativo
con i diritti ad esso assegnati in base al ruolo di afferenza
2) Inserendo credenziali errate o scadute, l’ODV non consente alcun accesso al sistema, mostrando
l’errore a video e consentendo di ripetere l’immissione nei limiti previsti per credenziali errate
3) In caso di primo accesso da parte di un utente, l’ODV obbliga l’utente a cambiare la propria
password assegnata automaticamente da SLT all’atto della sua creazione. Questo viene ottenuto
accendendo un flag dell’utente che dice di cambiare password al login.
4) Nel caso l’account risulti scaduto, l’ODV impedisce all’utente l’accesso.
Inoltre l’ODV provvede a registrare come evento di log qualsiasi operazione di login o logout.
Le operazioni sopra riportate realizzano le SFR FIA_AFL.1, FIA_ATD.1, FIA_SOS.1, FIA_UAU.1,
FIA_UID.2, FAU_GEN.1.
7.3. ODV_AC – ACCESS CONTROL
L’ODV, mediante le “Componenti di controllo accessi”, definisce soggetti, oggetti, operazioni e attributi che,
sotto il controllo delle TSF, realizzano le funzioni di sicurezza dell’ODV. Di seguito le operazioni che l’ODV
effettua sotto il controllo delle TSF:
 L’ODV mediante le funzioni del modulo CPS verifica lo stato di collegamento dei sistemi su strada.
 L’ODV mediante le funzioni del modulo CONFIGURATORE mantiene una lista degli utenti e abilita
l’utente ad uno specifico ruolo tra quelli previsti (Amministratore, Superutente, Operatore,
Manutentore).
L’accesso a queste operazioni viene realizzato dalle TSF che supportano le SFR FDP_ACC.1, FDP_ACF.1,
e FMT_SMR.1.
7.4. ODV_AUD - AUDITING
L’ODV controlla le operazioni effettuate sul SCE e per ognuna di quelle nel seguito descritte, eseguita dai
relativi moduli applicativi, viene memorizzata nel file di log eventi l’evento corrispondente contenente data ed
ora, utente, tipo di operazione effettuata.
Le operazioni che generano un evento nel file di log sono le seguenti:
1) Per ogni tentativo, riuscito o meno, di login mediante la digitazione del nome utente e della password
l’ODV archivia nel file di log degli eventi le informazioni identificative dell’evento.
2) Per ogni azione compiuta da utenti del sistema mediante i tre moduli: Client operazionale, Configuratore
e Supervisore, l’ODV archivia nel file di log degli eventi le informazioni identificative dell’evento.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 39 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
3) Per ogni operazione di invio a SCNTT delle informazioni di transito l’ODV tiene traccia cronologica della
operazioni di lettura e scrittura effettuate dal modulo Interfaccia con SCNTT.
4) Per ogni operazione di cancellazione dei transiti per il superamento del tempo di conservazione l’ODV
registra l’evento nel file di log degli eventi.
Queste operazioni vengono fatte tramite il modulo “Core Gestionale” del Sistema Centrale di Elaborazione e
realizzano le SFR FAU_GEN.1.
7.5. ODV_MGMT - MANAGEMENT
L’ODV, mediante le funzioni di sicurezza ODV_AC – Access Control consente l’accesso alle funzioni dell’ODV
agli utenti autorizzati. L’ODV, come descritto nel par. 2.6 del Security Target, gestisce mediante il modulo
applicativo Configuratore i seguenti ruoli utente: Amministratore, Superutente, Operatore e Manutentore.
L’ODV mediante il modulo applicativo Configuratore di SCE consente ad un utente appartenente al ruolo di
Amministratore di gestire tutti i parametri del sistema. In particolare consente la gestione di ruoli e utenti in
termini di: inserimento e gestione dei ruoli, gestione dei ruoli assegnati ad ogni utente, inserimento dei nuovi
utenti, modifica delle autorizzazioni degli utenti, disabilitazione/abilitazione delle utenze del sistema,
disattivazione/riattivazione di utenti e sistemi su strada, modifica del tempo di conservazione delle immagini,
assegnazione dei Sistemi su Strada agli utenti appartenenti al ruolo Operatore, in modo che venga creato
l’abbinamento fra Sistema su strada e Operatore.
In particolare relativamente alla modifica dei tempi di conservazione delle immagini l’utente appartenente al
ruolo di Amministratore, mediante il modulo applicativo Configuratore di SCE, può modificare i parametri di
data retention sia dei transiti, sia degli allarmi di transito associati alla lista C. In ogni modo questo utente
potrà modificare detti valori solo aumentando i parametri di data retention impostati come default
all’inizializzazione del sistema e che sono fissati in: 15 gg per i transiti e 90 gg per gli allarmi di transito
associati alla lista C.
Ad ogni operazione sopra descritta l’ODV assegna un riferimento temporale affidabile alla registrazione.
Queste operazioni realizzano le SFR FMT_SMF.1, FMT_MSA.1, FMT_MSA.3, FMT_SMR.1, FMT_MTD.1.
7.6. ODV_DP – DATA PROTECTION
L’ ODV si pone l’obiettivo di garantire la riservatezza ed integrità dei dati trattati, in maniera adeguata al livello
di garanzia prescelto, attraverso le operazioni di seguito illustrate.
I dati raccolti dalle telecamere vengono spediti dalle stesse al SCE per la memorizzazione nel DB Oracle. In
caso di interruzione del collegamento fra le telecamere ed il SCE, le telecamere hanno la capacità di trattenere
le immagini in forma cifrata nella propria memoria SD, fino al ripristino del collegamento.
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 40 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
Gestione dei dati
1) L’allarme di transito può ricadere in una delle tipologie possibili: allarme legato alla rilevazione di targa
in lista A1, A2, C, lista locale; allarme legato alle soglie di traffico; allarme di tipo targa mancante o
parzialmente leggibile; allarme di tipo merci pericolose.
2) L’allarme viene visualizzato soltanto dagli operatori loggati e appartenenti ai gruppi la cui area di
competenza contiene il varco in cui esso ha avuto origine.
3) Nel caso di allarme derivante dalla lista C, esso viene notificato agli operatori loggati e appartenenti
ai gruppi competenti, solo se la rispettiva targa è configurata come visibile.
4) In caso di transito che non ha generato allarmi o che ha generato un allarme di interesse locale (targa
in lista definita localmente, targa in lista A1 o A2, targa assente o parzialmente leggibile, merci
pericolose), entro 30 minuti dal riconoscimento del transito stesso l’ODV tenta l’invio dei metadati
relativi al transito e dell’immagine completa in bianco e nero al metodo updateTransits esposto dal
web service di SCNTT. SCNTT risponderà inviando un array (Result) con i transiti non archiviati, dal
quale sarà possibile ricavare gli eventuali errori presenti.
5) In caso di errori presenti, si procede alla correzione dei dati errati e si esegue nuovamente l’invio,
entro i tempi previsti di conservazione del dato (15 gg). In caso di irraggiungibilità di SCNTT o di errori
imputabili a SCNTT, si ritenta l’invio successivamente, fino a esito positivo e comunque entro i tempi
previsti di conservazione del dato (15 gg).
6) In caso di transito che ha generato allarmi di interesse globale (targa in lista C), l’ODV tenta l’invio in
tempo reale al metodo updateAlarms esposto dal web service di SCNTT dei metadati relativi
all’allarme, dell’immagine completa in bianco e nero e dell’immagine di contesto a colori. SCNTT
risponderà inviando un array (Result) con i transiti non archiviati, dal quale sarà possibile ricavare gli
eventuali errori presenti.
7) In caso di errori presenti, si procede alla correzione dei dati errati e ad eseguire nuovamente l’invio,
entro i tempi previsti di conservazione del dato (90 gg). In caso di irraggiungibilità di SCNTT o di errori
imputabili a SCNTT, si ritenta l’invio successivamente, fino a esito positivo e comunque entro i tempi
previsti di conservazione del dato (90 gg).
Queste operazioni realizzano le SFR FRU_FLT.1, FDP_ETC.1, FDP_RIP.1.
7.7. TABELLA DI SINTESI
La tabella seguente fornisce la mappatura dei SFR con le funzioni di sicurezza dell’ODV.
ODV_IDAU ODV_AC ODV_AUD ODV_MGMT ODV_DP
FAU_GEN.1 X X
Kapsch TrafficCom S.r.l.
Security Target SLT v_2_3.docx Pag. 41 di 41
Il presente documento costituisce, ai sensi dell’Art. 13, comma 5, lett. a) del D.lgs. 12 aprile 2006, n. 163, segreto tecnico contenente informazioni circa i processi di lavorazione del sistema Kapsch.
Sono inoltre riservati tutti i diritti a termine di legge, vietata la riproduzione e la divulgazione.
ODV_IDAU ODV_AC ODV_AUD ODV_MGMT ODV_DP
FDP_ACC.1 X
FDP_ACF.1 X
FDP_RIP.1 X
FIA_AFL.1 X
FIA_ATD.1 X
FIA_SOS.1 X
FIA_UAU.1 X
FIA_UID.2 X
FMT_MSA.1 X
FMT_MSA.3 X
FMT_SMF.1 X
FMT_MTD.1 X
FMT_SMR.1 X X
FRU_FLT.1 X
FDP_ETC.1 X
Tabella 9 - Sintesi dei SFR soddisfatti dalle funzioni dell’ODV