ISO/TS 19299:2015

SPÉCIFICATION ISO/TS
TECHNIQUE 19299
Première édition
2015-10-01
Perception de télépéage — Cadre de
sécurité
Electronic fee collection — Security framework
Numéro de référence
©
ISO 2015
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2015, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. +41 22 749 01 11
Fax +41 22 749 09 47
copyright@iso.org
www.iso.org
ii © ISO 2015 – Tous droits réservés

Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 3
3 Termes et définitions . 4
4 Symboles et abréviations .10
5 Modèle de confiance .11
5.1 Vue d’ensemble .11
5.2 Relations de confiance entre les parties prenantes .11
5.3 Modèle de confiance technique .13
5.3.1 Généralités .13
5.3.2 Modèle de confiance pour les relations entre le percepteur de péage (TC)
et le prestataire de services de péage (TSP) .13
5.3.3 Modèle de confiance pour les relations entre le prestataire de services de
péage (TSP) et l’utilisateur de service (SU) .14
5.3.4 Modèle de confiance pour les relations du gestionnaire de
l’interopérabilité (IM) .14
5.4 Mise en œuvre.14
5.4.1 Instauration des relations de confiance .14
5.4.2 Renouvellement et révocation des relations de confiance .15
5.4.3 Emission et révocation des certificats de l’autorité de certification (CA)
subordonnée et d’entité finale .16
5.4.4 Profil et format de certificat et de liste de révocation de certificats (CRL) .16
5.4.5 Extensions de certificat .16
6 Exigences relatives à la sécurité .18
6.1 Généralités .18
6.2 Système de management de la sécurité de l’information (ISMS) .19
6.3 Interfaces de communication .19
6.4 Stockage de données .20
6.5 Percepteur de péage .20
6.6 Prestataire de services de péage (TSP) .22
6.7 Gestionnaire de l’interopérabilité (IM) .24
6.8 Limitation des exigences .24
7 Mesures de sécurité — Contre-mesures .25
7.1 Vue d’ensemble .25
7.2 Mesures de sécurité générales .25
7.3 Mesures de sécurité relatives aux interfaces de communication .26
7.3.1 Généralités .26
7.3.2 Interface DSRC-EFC .27
7.3.3 Interface CCC .28
7.3.4 Interface LAC .29
7.3.5 Interface entre le système frontal et le système dorsal du prestataire de
services de péage (TSP) .29
7.3.6 Interface entre le percepteur de péage (TC) et le prestataire de services
de péage (TSP) .30
7.3.7 Interface ICC.31
7.4 Mesures de sécurité de bout en bout .31
7.5 Mesures de sécurité relatives au prestataire de services de péage (TSP) .33
7.5.1 Mesures de sécurité relatives au système frontal .33
7.5.2 Mesures de sécurité relatives au système dorsal . .34
7.6 Mesures de sécurité relatives au percepteur de péage (TC) .34
7.6.1 Mesures de sécurité relatives à l’équipement au sol (RSE) .34
7.6.2 Mesures de sécurité relatives au système dorsal . .35
7.6.3 Autres mesures de sécurité relatives au percepteur de péage (TC) .36
8 Spécifications de sécurité relatives à la mise en œuvre d’une interface interopérable .36
8.1 Généralités .36
8.1.1 Sujet .36
8.1.2 Signature et algorithmes de hachage .36
8.2 Spécifications de sécurité relatives au télépéage DSRC .36
8.2.1 Sujet .36
8.2.2 OBE (On-Board Equipment) .37
8.2.3 Equipement routier .37
9 Gestion de clés .37
9.1 Vue d’ensemble .37
9.2 Clés asymétriques .37
9.2.1 Echange de clés entre les parties prenantes .37
9.2.2 Génération et certification de clés .38
9.2.3 Protection des clés .38
9.2.4 Application .38
9.3 Clés symétriques .38
9.3.1 Généralités .38
9.3.2 Echange de clés entre les parties prenantes .39
9.3.3 Cycle de vie des clés .39
9.3.4 Stockage et protection de clé .41
9.3.5 Clés de session .42
Annexe A (normative) Profils de sécurité .43
Annexe B (normative) Formulaire ICS .48
Annexe C (informative) Objectifs des parties prenantes et exigences génériques .67
Annexe D (informative) Analyse des menaces .72
Annexe E (informative) Politiques de sécurité .134
Annexe F (informative) Exemple de politique de sécurité d’un service européen de
télépéage (SET) .141
Annexe G (informative) Recommandations relatives à une mise en œuvre axée sur la
vie privée .143
Annexe H (informative) Proposition relative aux certificats d’entité finale .145
Bibliographie .146
iv © ISO 2015 – Tous droits réservés

Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d’approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2 (voir www.
iso.org/directives).
L’attention est appelée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant
les références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de
l’élaboration du document sont indiqués dans l’Introduction et/ou dans la liste des déclarations de
brevets reçues par l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité, à l’intention des utilisateurs et ne sauraient constituer
un engagement.
Pour une explication de la signification des termes et expressions spécifiques de l’ISO liés à
l’évaluation de la conformité, ou pour toute information au sujet de l’adhésion de l’ISO aux principes
de l’OMC concernant les obstacles techniques au commerce (OTC), voir le lien suivant: Avant-propos —
Informations supplémentaires.
L’ISO/TS 19299 a été élaborée par le comité européen de normalisation (CEN), en collaboration
avec le comité technique CEN/TC 204, Systèmes intelligents de transport, conformément à l’accord de
coopération technique entre l’ISO et le CEN (Accord de Vienne).
Cette première édition de l’ISO/TS 19299 annule et remplace la CEN/TS 16439:2013.
Introduction
Note explicative
Le processus de développement d’un concept de sécurité et de sa mise en œuvre visant à protéger
un système existant de perception du télépéage (EFC, Electronic Fee Collection) inclut normalement
plusieurs étapes, notamment:
— la définition des objectifs de sécurité ainsi que des déclarations de politique dans le cadre d’une
politique de sécurité;
— une analyse des menaces, associée à une évaluation des risques afin de définir les exigences de sécurité;
— le développement des mesures de sécurité suivies par le développement des spécifications
d’essai de sécurité.
Anglais Français
POLICIES POLITIQUES
Security objectives Objectifs de sécurité
Policy statements Déclarations de politique
REQUIREMENTS EXIGENCES
Threat analysis Analyse des menaces
Security requirements Exigences de sécurité
SPECIFICATIONS SPECIFICATIONS
Security measures Mesures de sécurité
Specifications of security measures Spécifications de mesures de sécurité
TEST PROCEDURES PROCEDURES D’ESSAI
Test specifications Spécifications d’essai
Figure 1 — Plan de développement des documents de sécurité
vi © ISO 2015 – Tous droits réservés

Pour la deuxième étape, chaque acteur d’un système EFC existant doit mettre en œuvre les mesures
de sécurité définies et superviser leur efficacité. Les mesures de sécurité ne fonctionnant pas ou
fonctionnant de manière incorrecte doivent être améliorées. Le développement du cadre de sécurité EFC
s’attache à suivre cette approche autant que possible. La méthodologie utilisée doit tenir compte des
limitations suivantes:
— Il n’existe aucune politique de sécurité: la politique de sécurité peut seulement être définie par les
parties prenantes responsables, et son rayon d’action est uniquement limité par la réglementation
et les lois applicables. Néanmoins, la présente Spécification technique propose quelques exemples
simples des politiques de sécurité possibles (de l’Annexe E à l’Annexe F).
— Aucune évaluation des risques n’est possible: l’évaluation des risques compare la perte possible pour
la partie prenante et les ressources nécessaires (par exemple équipement, connaissances, temps,
etc.) à la réalisation d’une attaque. Il s’agit d’une évaluation comparative des coûts et bénéfices de
chaque contre-mesure, ce qui n’est possible que dans le cas d’un système mis en œuvre.
— Pendant le développement de la présente Spécification technique, aucune conception ou configuration
système spécifique n’a été envisagée à des fins d’applicabilité à l’échelle universelle. Seules les
normes EFC de base disponibles et les commentaires reçus vis-à-vis de la CEN/TS 16439:2013
(l’édition précédente du cadre de sécurité EFC) ont été pris comme références. Outre le cadre de
sécurité EFC présent, les détails techniques spécifiques d’un système particulier (par exemple
serveurs, centres informatiques et éléments décentralisés comme les équipements au sol) doivent
être pris en considération lors de la mise en œuvre.
La sélection des exigences et des mesures de sécurité respectives pour un système EFC existant dépend
de la politique de sécurité et de l’évaluation des risques des systèmes des différentes parties prenantes.
Etant donné qu’il n’existe pas de politique de sécurité générale valide et qu’aucune évaluation des
risques ne peut être fournie, la cadre de sécurité EFC propose un ensemble d’exigences et de mesures de
sécurité couvrant le plus de menaces possibles, sans prétendre à l’exhaustivité.
Cependant, il existe une condition de conformité à la présente Spécification technique: si une exigence
est sélectionnée, la ou les mesures de sécurité associées doivent être mises en œuvre.
Pour comprendre le contenu de la présente Spécification technique, il convient que le lecteur ait
connaissance des hypothèses méthodologiques utilisées pour son élaboration. La sécurité d’un plan EFC
(interopérable) dépend de la réussite de la mise en œuvre et du bon fonctionnement de plusieurs
processus, systèmes et interfaces. Seule une sécurité de bout en bout fiable garantit le fonctionnement
précis et fiable des composants d’interaction des environnements de perception du péage. C’est
pourquoi ce cadre de sécurité couvre également les systèmes ou interfaces qui ne sont pas spécifiques
au concept EFC (notamment les connexions de back-office). Le cadre de sécurité indépendant de
l’application pour ces parties et interfaces, le système de management de la sécurité de l’information
(ISMS, Information Security Management System), est fourni dans la collection de normes ISO 2700x.
Le processus d’élaboration de la présente Spécification technique est décrit de manière succincte ci-après:
a) Définition des objectifs des parties prenantes et des exigences génériques qui constituent le
principal motif des exigences de sécurité (voir Annexe C). Une politique de sécurité possible
supportée par un ensemble de déclarations de politique est fournie à l’Annexe E, et un exemple de
politique de sécurité SET (Service Européen de Télépéage) est donné à l’Annexe F.
b) En fonction du modèle de rôle EFC et des définitions supplémentaires de la norme d’architecture EFC
(ISO 17573), la spécification définit un modèle de système EFC abstrait comme base pour une
analyse des menaces, la définition des exigences et les mesures de sécurité.
c) Les menaces inhérentes au modèle de système EFC et à ses actifs sont analysées par deux méthodes
distinctes: une analyse basée sur les attaques et une analyse basée sur les actifs. La première
approche envisage plusieurs scénarios du point de vue des agresseurs. La seconde approche étudie
de manière approfondie les menaces à l’égard des différents actifs identifiés (entités corporelles
et incorporelles). Cette approche, même si elle introduit une certaine redondance, garantit
l’exhaustivité et la couverture d’une gamme plus vaste de risques (voir Annexe D).
d) La spécification des exigences (voir Article 6) est basée sur les menaces identifiées à l’Annexe D.
Chaque exigence est au minimum motivée par une menace et au moins une exigence couvre
chaque menace.
e) La définition des mesures de sécurité (voir Article 7) propose une description générale des
méthodes recommandées possibles pour couvrir les exigences élaborées.
f) Les spécifications de sécurité relatives à la mise en œuvre d’une interface interopérable (voir
Article 8) fournissent des définitions détaillées, par exemple pour les authentificateurs de
messages. Ces spécifications offrent une extension de sécurité aux normes d’interface applicables
correspondantes.
g) Les exigences fondamentales de gestion de clés prenant en charge la mise en œuvre des interfaces
interopérables sont décrites à l’Article 9. L’environnement de perception du péage utilise
des éléments cryptographiques (clés, certificats, liste de révocation de certificats, etc.) pour
prendre en charge les services de sécurité tels que la confidentialité, l’intégrité, l’authenticité et
la non-répudiation. Le présent paragraphe de la spécification couvre l’instauration (initiale) de
l’échange de clés entre les parties prenantes et plusieurs procédures opérationnelles telles que le
renouvellement de clés, la révocation de certificats, etc.
h) Un modèle de confiance général (voir Article 5) est défini pour former la base de la mise en œuvre
de procédures cryptographiques afin de garantir la confidentialité, l’intégrité et l’authenticité des
données échangées. Dans ce contexte, le cadre de sécurité référence les normes internationales
approuvées pour la mise en œuvre de procédures cryptographiques améliorées par des détails EFC
spécifiques lorsque cela s’avère nécessaire.
Une partie prenante d’un plan EFC souhaitant utiliser ce cadre de sécurité doit notamment:
— définir une politique de sécurité pour le plan EFC (pouvant impliquer plus d’une partie prenante
dans un plan EFC interopérable). Quelques exemples de la politique de sécurité et de ses éléments
sont fournis (à l’Annexe E et à l’Annexe F) à titre d’aide à l’utilisation de la présente Spécification
technique pour concevoir un système sécurisé pour un cadre d’interopérabilité concret (y compris
le service européen de télépéage [SET]);
— identifier les processus, systèmes et interfaces applicables, puis les associer au cadre de sécurité EFC;
— sélectionner les exigences de sécurité correspondantes en fonction de la politique de sécurité;
— mettre en œuvre les mesures de sécurité associées aux exigences sélectionnées;
— fournir une preuve de la conformité de ses systèmes, processus et interfaces aux exigences définies
dans la présente Spécification technique. La preuve peut être une autodéclaration, un audit interne
ou externe, voire d’autres certifications.
Modèle de rôle EFC
La présente Spécification technique satisfait au modèle de rôle défini dans l’ISO 17573. Selon ce modèle
de rôle, le percepteur de péage (TC, Toll Charger) est le fournisseur de l’infrastructure de péage ou du
service de transport et ainsi le destinataire des redevances du réseau routier. Le TC est l’acteur associé
au rôle Perception du péage (voir Figure 2).
viii © ISO 2015 – Tous droits réservés

Anglais Français
Interoperability management Gestion de l’interopérabilité
Service provision Fourniture du service
Toll charging Perception du télépéage
Service usage Utilisation du service
Figure 2 — Modèle de rôle sous-jacent de la présente Spécification technique
Les prestataires de services de péage (TSP, Toll Service Provider) fournissent un équipement embarqué
(OBE, On-Board Equipment) aux utilisateurs du service d’infrastructure ou de transport à péage.
Les TSP sont chargés de fournir l’OBE qui sera utilisé pour la collecte des données, ce qui permet
au TC d’envoyer une demande au TSP en ce qui concerne l’utilisation de l’infrastructure ou du service
de transport par leurs utilisateurs de services (SU, Service User). Dans les systèmes autonomes,
chaque TSP fournit les déclarations de péage au TC qui exploite le système autonome. Il se peut qu’un
tel TC reçoive les déclarations de péage de plus d’un TSP. Dans les systèmes de communications
dédiées à courte portée (DSRC, Dedicated Short-Range Communication), le TC reçoit les déclarations de
péage principales de son propre équipement au sol (RSE, Road-Side Equipment) qui communique avec
l’OBE du TSP ainsi que les données de perception supplémentaires, si nécessaires, du TSP. La gestion
de l’interopérabilité (IM, Interoperability Management) représentée à la Figure 2 inclut toutes les
spécifications et activités qui permettent de définir et de maintenir un ensemble de règles gouvernant
l’environnement global de perception du péage.
Le modèle de confiance défini dans la présente Spécification technique est basé sur le modèle de rôle
ci-dessus et constitue également la base technique pour la protection de la communication des données
entre les entités du modèle de rôle. Outre la sécurité des communications, la mise en œuvre et la gestion
sécurisées du système dorsal et des autres équipements de l’infrastructure EFC doivent être fiables. Un
percepteur de péage (TC) ou un prestataire de services de péage (TSP) en conformité avec la présente
Spécification technique doit être capable de fournir une preuve du management de la sécurité exigé.
Une telle preuve constitue la base de relations de confiance entre les entités impliquées.
La Figure 3 ci-après représente le modèle de système EFC abstrait utilisé pour l’analyse des menaces, et la
définition des exigences de sécurité et des mesures de sécurité associées pour la présente Spécification
technique. La présente Spécification technique s’appuie sur la supposition d’un OBE qui est dédié
exclusivement à des fins EFC et ne s’intéresse pas aux services à valeur ajoutée basés sur un OBE EFC, ni
aux plates-formes OBE plus génériques (également appelées «stations STI embarquées») utilisées pour
héberger l’application EFC. L’OBE peut soit être connecté à un compte central, soit utiliser un moyen de
paiement tel qu’une carte à puce intégrée (ICC, Integrated Chip Card) ou un paiement mobile pour un
système EFC à compte embarqué. Les transactions financières éventuelles transmises sur le moyen de
paiement ne relèvent pas du domaine d’application de la présente Spécification technique.
ANPR
GNSS
Position&
Time
User
TollServiceProvider
Contract
contact(less) ServicePoint
ICC
Driver Personnel
Customization,
Maintenance
contact(less)
HMI
optional
Service Provider
OBE CN OBE
Valueadded
BackEnd
Proxy
services
Power,
Tacho,
DSRC
CAN,
etc.
TollCharger
Toll Charger
BackEnd
Vehicle RSE,
Enforcement
Personnel
x © ISO 2015 – Tous droits réservés
Equipmentsupplier,serviceprovider,etc.

Anglais Français
GNSS position & time Position et heure GNSS
User Usager
Driver Conducteur
HMI IHM
Contact(less) (sans) contact
Value added services Services à valeur ajoutée
Power, tacho, CAN, etc. Alimentation électrique, tachygraphe,
bus CAN, etc.
Vehicle Véhicule
Toll service provider Prestataire de services de péage
Service point Point de service
Contract Contrat
Contact(less) (sans) contact
Customization, maintenance Personnalisation, maintenance
Optional OBE proxy Proxy OBE facultatif
Service provider back end Système dorsal du prestataire de ser-
vices
Toll charger Percepteur de péage
RSE, enforcement RSE, contrôle sanction
Toll charger back end Système dorsal du percepteur de péage
Equipment supplier, service provider, Fournisseur d’équipements, fournisseur
etc. de services, etc.
Figure 3 — Modèle de système EFC du cadre de sécurité EFC
Relation avec les autres normes de sécurité
Plusieurs normes génériques et spécifiques et Rapports techniques traitent déjà des problèmes de
sécurité relatifs aux technologies de l’information. La présente Spécification technique utilise ces
normes existantes et élargit leur usage aux applications EFC. Le cadre référence et adapte les techniques
et méthodologies de sécurité découlant de ces normes.
La Figure 4 représente le contexte du cadre de sécurité EFC par rapport aux autres normes de sécurité.
Il ne s’agit pas d’une description exhaustive, car seules les normes les plus pertinentes sont indiquées,
c’est-à-dire les normes qui ont contribué le plus à la présente Spécification technique. Les normes
qui sont utilisées et référencées directement sont en noir (les autres sont en gris). Les autres normes
pouvant fournir d’autres informations de sécurité sont données à titre d’information et d’exhaustivité
seulement, mais ne sont pas utilisées.
ETSI TR 102 731
(Essential Counter-
measures for Co-operative
ITS)
Digital signatures
Equipment management
Anglais Français
IT – Open systems interconnection Technologies de l’information – Interconnexion de
systèmes ouverts (OSI)
ISO 7498-2 ISO 7498-2
Basic reference Model – Part 2: Security Architecture Modèle de référence de base – Partie 2: Architecture
de sécurité
ISO/IEC 10171-1 to 7 ISO/IEC 10171-1 à 7
Security frameworks for open systems Cadres de sécurité pour les systèmes ouverts
ISO/IEC 9594-8 (X.509) ISO/IEC 9594-8 (X.509)
The Directory: Public-key and attribute certificate The Directory: Public-key and attribute certificate
frameworks frameworks
Security techniques – Security measures and algo- Techniques de sécurité – Mesures de sécurité et algo-
rithms rithmes
ISO/IEC 10118-3 ISO/IEC 10118-3
Dedicated hash-functions Dedicated hash-functions
ISO/IEC 9797-1 and 2 ISO/IEC 9797-1 et 2
MACs MACs
ISO/IEC 14888-1 to 3 ISO/IEC 14888-1 à 3
Digital signatures Digital signatures
ETSI/TR 102 731 (Essential Counter-measures for ETSI/TR 102 731 (Essential Counter-measures for
Co-operative ITS) Co-operative ITS)
ISO/IEC 18033-1 to 4 ISO/IEC 18033-1 à 4
Encryption algorithms Encryption algorithms
xii © ISO 2015 – Tous droits réservés

ISO/IEC 11770-1 to 4 ISO/IEC 11770-1 à 4
Key management Key management
CEN ISO/TS 19299 CEN ISO/TS 19299
Electronic fee collection – Security framework Perception de télépéage – Cadre de sécurité
Reference, make use of standards and best practice Référencement et utilisation de normes et recomman-
dations
Evaluation criteria for IT security (common criteria) Critères d’évaluation de la sécurité informatique (cri-
tères communs)
Equipment evaluation and certification
Evaluation et certification de l’équipement
ISO/IEC 18045 ISO/IEC 18045
Methodology for IT security evaluation Methodology for IT security evaluation
ISO/TS 17574 ISO/TS 17574
EFC – Guidelines for security protection profile EFC – Guidelines for security protection profile
ISO/IEC/TR 15446 ISO/IEC/TR 15446
Guide for the production of protection profiles and Guide for the production of protection profiles and
security targets security targets
ISO/IEC 15408 Part 1 to 3 ISO/IEC 15408-1 à 3
Evaluation criteria for IT security (common criteria) Evaluation criteria for IT security (common criteria)
IT – Security techniques – Information security Technologies de l’information – Techniques de sécu-
management systems rité – Systèmes de management de la sécurité de
l’information
ISO/IEC 27001 ISO/IEC 27001
Requirements Exigences
ISO/IEC 27002 ISO/IEC 27002
(BS 7799) (BS 7799)
Code of practice Code de la bonne pratique
ISO/IEC 27003 ISO/IEC 27003
Implementation Guidance Implementation Guidance
ISO/IEC 27005 ISO/IEC 27005
Risk management Gestion des risques
ISO/IEC 27000 ISO/IEC 27000
Overview and vocabulary Vue d’ensemble et vocabulaire
Figure 4 — Normes de sécurité dans le contexte du cadre de sécurité EFC
Chaque groupe de normes représenté à la Figure 4 assure les fonctionnalités suivantes:
— Techniques de sécurité — Mesures de sécurité et algorithmes: ce groupe de normes rassemble
les mesures de sécurité essentielles et les algorithmes cryptographiques recommandés, incluant
également les directives relatives à une utilisation précise.
— Technologies de l’information — Interconnexion de systèmes ouverts: ce groupe de normes
définit les mécanismes utilisés pour établir des communications sécurisées entre des systèmes
ouverts. Les normes décrivent quelques-unes des exigences de sécurité dans les domaines de
l’authentification et d’autres services de sécurité en proposant un ensemble de cadres.
— Critère d’évaluation de la sécurité informatique (critères communs): ce groupe de normes
définit des méthodologies et des processus pour l’évaluation de la sécurité et la certification de la
majorité des catégories de produits utilisés dans l’environnement EFC. Les flèches à l’intérieur du
groupe mettent en évidence la relation entre les normes dans le sens ascendant.
— Technologies de l’information — Techniques de sécurité — Système de management de la
sécurité de l’information (ISMS): ce groupe de normes définit les exigences et les directives
relatives à la mise en œuvre des systèmes de management de la sécurité pour tous les types
d’organisations. Les normes conviennent parfaitement aux solutions de sécurité du système dorsal
et des autres équipements fixes ou installés (y compris les logiciels des systèmes EFC).
Il est permis d’utiliser une certification ISO/IEC 27001 correspondante d’un percepteur de péage (TC)
ou d’un prestataire de services de péage (TSP) pour prouver la conformité à la présente Spécification
technique, sous réserve que le domaine d’application et les déclarations d’applicabilité (SoA, Statement of
Applicability) incluent les processus métier EFC spécifiés dans l’ISO 17573 et que les exigences de sécurité
sélectionnées et leurs mesures de sécurité associées fournies par la présente Spécification technique
soient appliquées, par exemple en les utilisant dans les catalogues contenant les mesures de sécurité et
les objectifs de contrôle. La Figure 5 ci-après montre comment cette approche fonctionne en parallèle.
La première partie des deux méthodes consiste à analyser les processus métiers suivis d’une analyse
des menaces. Une analyse des risques commune combine l’analyse générique et l’analyse spécifique au
système EFC (ainsi que les résultats associés) dans les mesures et les contrôles de sécurité respectifs.
Information Security Management Systems - ISO 27001
Anglais Français
Information security management systems – Système de management de la sécurité de l’informa-
ISO 27001 tion – ISO 27001
Generic company business processes Processus métier d’entreprises génériques
Generic threats – ISO 27005 Menaces génériques – ISO 27005
EFC business processes – ISO 15573 Processus métier EFC – ISO 15573
EFC specific threats – this Technical specification Menaces spécifiques à l’EFC – la présente Spécification
technique
Risk evaluation – ISO 27005 Evaluation des risques – ISO 27005
General security measures & controls considering Mesures et contrôles de sécurité généraux selon
ISO 27002 l’ISO 27002
xiv © ISO 2015 – Tous droits réservés

EFC security measures & controls – this Technical Mesures et contrôles de sécurité EFC – la présente
specification Spécification technique
Figure 5 — Domaine d’application relatif au système de management de la sécurité de
l’information (ISMS)
En outre, le cadre de sécurité EFC utilise les méthodes existantes d’analyse des menaces ainsi que
l’analyse des menaces existante en rapport avec l’EFC ou les STI [par exemple ETSI/TR 102 893
(systèmes de transport intelligents, sécurité, menace, vulnérabilité et analyse des risques)]
SPÉCIFICATION TECHNIQUE ISO/TS 19299:2015(F)
Perception de télépéage — Cadre de sécurité
1 Domaine d’application
Le domaine d’application général de la présente Spécification technique consiste à fournir un cadre
de sécurité de l’information pour l’ensemble des entités organisationnelles et techniques d’un plan de
perception du télépéage (EFC), et plus particulièrement pour les interfaces entre elles, sur la base de
l’architecture système définie dans l’ISO 17573. Le cadre de sécurité décrit un ensemble d’exigences et
de mesures de sécurité associées destinées à être mises en œuvre par les parties prenantes, garantissant
ainsi un fonctionnement sécurisé de leur partie d’un système EFC, tel que l’exige la politique de sécurité
d’un environnement de confiance.
Le domaine d’application de la présente Spécification technique inclut:
— la définition d’un modèle de confiance (voir Article 5);
Principes et hypothèses de base pour l’établissement de relations de confiance entre les parties
prenantes.
— les exigences de sécurité (voir Article 6);
— les mesures de sécurité — contre-mesures (voir Article 7);
Exigences de sécurité relatives à la prise en charge des mises en œuvre du système EFC actuel.
— les spécifications de sécurité relatives à la mise en œuvre de l’interface (voir Article 8);
Ces spécifications offrent une extension de sécurité aux normes correspondantes. La Figure 5 ci-
avant représente les interfaces applicables et les normes d’interface applicables correspondantes,
telles que représentées à la Figure 6.
— la gestion des clés (voir Article 9);
Couvre l’instauration (initiale) de l’échange de clés entre les parties prenantes et plusieurs
procédures opérationnelles telles que le renouvellement de clés, la révocation de certificats, etc.
— les profils de sécurité (voir Annexe A);
— la déclaration de conformité de la mise en œuvre (voir Annexe B) propose une liste de contrôle
devant être utilisée par un fournisseur d’équipement, un chargé de mise en œuvre d’un système ou
l’acteur d’un rôle pour déclarer sa conformité à la présente Spécification technique;
— les objectifs généraux de sécurité de l’information des parties prenantes (voir Annexe C) qui
constituent le principal motif des exigences de sécurité;
— l’analyse des menaces (voir Annexe D) inhérentes au modèle de système EFC et à ses actifs en
utilisant deux méthodes complémentaires distinctes, une analyse basée sur les attaques et une
analyse basée sur les actifs;
— des exemples de politiques de sécurité (voir Annexe E et Annexe F);
— les recommandations relatives à une mise en œuvre axée sur la protection de la vie privée (voir
Annexe G);
— une proposition relative aux certificats d’entité finale (voir Annexe H).
Anglais Français
Charge data Données d’imputation
Context data Données contextuelles
Customization data Données de personnalisation
Toll service provider back end Système dorsal du prestataire de services de péage
Charging identification Identification de la perception
Charging identification & transfer charging informa- Identification de la perception et transfert des infor-
tion mations de perception
Transit information Informations de transfert
User identification Identification de l’usager
OBE interrogation Interrogation de l’OBE
RSE localisation data Données de localisation du RSE
Checking of itinerary freezing in real time Contrôle du gel d’itinéraire en temps réel
Trust objects Objets de confiance
EFC context data Données contextuelles EFC
Exception lists Listes d’exceptions
Payment claims Demandes de paiement
Billing details Détails de facturation
Toll declarations Déclarations de péage
Itinerary freezing (incl. toll declarations) Gel d’itinéraire (déclarations de péage incl.)
Checking of itinerary freezing via back end Contrôle du gel d’itinéraire via le système dorsal
Checking of toll declarations Contrôle des déclarations de péage
Claiming incorrectness Demande pour motif d’inexactitude
2 © ISO 2015 – Tous droits réservés

Toll charger back end Système dorsal du percepteur de péage
Figure 6 — Domaine d’application du cadre de sécurité EFC pour les communications sécurisées
Les éléments suivants ne relèvent pas du domaine d’application de la
...