ISO 19299:2020
(Main)Electronic fee collection — Security framework
Electronic fee collection — Security framework
This document defines an information security framework for all organizational and technical entities of an EFC scheme and for the related interfaces, based on the system architecture defined in ISO 17573-1. The security framework describes a set of security requirements and associated security measures. Annex D contains a list of potential threats to EFC systems and a possible relation to the defined security requirements. These threats can be used for a threat analysis to identify the relevant security requirements for an EFC system. The relevant security measures to secure EFC systems can then be derived from the identified security requirements.
Perception de télépéage — Cadre de sécurité
Ce document définit un cadre de sécurité de l'information pour toutes les entités organisationnelles et techniques d'un système EFC et pour les interfaces correspondantes, sur la base de l'architecture système définie dans la norme ISO 17573-1. Le cadre de sécurité décrit un ensemble d'exigences de sécurité et de mesures de sécurité associées. L'Annexe D contient une liste des menaces potentielles pour les systèmes EFC et une relation possible avec les exigences de sécurité définies. Ces menaces peuvent être utilisées pour une analyse des menaces afin d'identifier les exigences de sécurité pertinentes pour un système EFC. Les mesures de sécurité pertinentes pour sécuriser les systèmes EFC peuvent ensuite être dérivées des exigences de sécurité identifiées.
General Information
Relations
Buy Standard
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 19299
First edition
2020-08
Electronic fee collection — Security
framework
Perception de télépéage — Cadre de sécurité
Reference number
ISO 19299:2020(E)
©
ISO 2020
---------------------- Page: 1 ----------------------
ISO 19299:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO 19299:2020(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 3
5 Trust model . 4
5.1 Overview . 4
5.2 Stakeholders trust relations . 5
5.3 Technical trust model . 6
5.3.1 General. 6
5.3.2 Trust model for TC and TSP relations . 6
5.3.3 Trust model for TSP and service user relations . 7
5.3.4 Trust model for interoperability management relations . 7
5.4 Implementation . 7
5.4.1 Setup of trust relations . 7
5.4.2 Trust relation renewal and revocation . 8
5.4.3 Issuing and revocation of sub CA and end-entity certificates . 8
5.4.4 Certificate and certificate revocation list profile and format . 9
5.4.5 Certificate extensions . 9
6 Security requirements .10
6.1 General .10
6.2 Information security management system .11
6.3 Communication interfaces .12
6.4 Data storage .12
6.5 Toll charger .12
6.6 Toll service provider .14
6.7 Interoperability management .16
6.8 Limitation of requirements .17
7 Security measures — Countermeasures .17
7.1 Overview .17
7.2 General security measures .18
7.3 Communication interfaces security measures .18
7.3.1 General.18
7.3.2 DSRC-EFC interface . .19
7.3.3 CCC interface .20
7.3.4 LAC interface .21
7.3.5 Front End to TSP back end interface .21
7.3.6 TC to TSP interface .22
7.3.7 ICC interface .23
7.4 End-to-end security measures .24
7.5 Toll service provider security measures .25
7.5.1 Front end security measures .25
7.5.2 Back end security measures .26
7.6 Toll charger security measures .27
7.6.1 RSE security measures . .27
7.6.2 Back end security measures .28
7.6.3 Other TC security measures .28
8 Security specifications for interoperable interface implementation .29
8.1 General .29
8.1.1 Subject.29
© ISO 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO 19299:2020(E)
8.1.2 Signature and hash algorithms .29
8.2 Security specifications for DSRC-EFC .29
8.2.1 Subject.29
8.2.2 OBE .29
8.2.3 RSE .29
9 Key management .30
9.1 Overview .30
9.2 Asymmetric keys .30
9.2.1 Key exchange between stakeholders .30
9.2.2 Key generation and certification .30
9.2.3 Protection of keys .30
9.2.4 Application .31
9.3 Symmetric keys .31
9.3.1 General.31
9.3.2 Key exchange between stakeholders .31
9.3.3 Key lifecycle .32
9.3.4 Key storage and protection .33
9.3.5 Session keys .34
Annex A (normative) Security profiles .35
Annex B (informative) Implementation conformance statement (ICS) proforma .39
Annex C (informative) Stakeholder objectives and generic requirements .57
Annex D (informative) Threat analysis .61
Annex E (informative) Security policies .118
Annex F (informative) Example for an EETS security policy .124
Annex G (informative) Recommendations for privacy-focused implementation .126
Bibliography .128
iv © ISO 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO 19299:2020(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/TC
278 Intelligent transport systems, in accordance with the Agreement on technical cooperation between
ISO and CEN (Vienna Agreement).
This first edition cancels and replaces ISO/TS 19299:2015, which has been technically revised.
The main changes compared to the previous edition are as follows:
— added requirements and security measures for the use of common payment media according to
ISO/TS 21193;
— updated data protection considerations in Annex G, in order to take into account the European
Union’s new General Data Protection Regulation (i.e. Directive 2016/679/EC).
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO 19299:2020(E)
Introduction
Context of this document
The development process for a security concept and implementation to protect any existing electronic
fee collection (EFC) system normally includes several steps as follows (see Figure 1):
— definition of the security objectives and policy statements in a security policy;
— threat analysis with risk assessment to define the security requirements;
— development of the security measures followed by the development of security test specifications.
Figure 1 — Development path for the security documents
Each actor in an existing EFC system implements the defined security measures and supervises their
effectiveness. When a security measure is found not working properly, an improvement process is
started. The development of the EFC security framework follows this approach, with the following
limitations:
— No standard security policy exists, nor can it be defined: The security policy can only be defined by
the responsible stakeholders and it is limited by laws and regulations. Nonetheless, this document
provides basic examples of possible security policies (in Annex E to Annex F).
— No standard risk assessment is possible: Risk assessment compares possible losses to stakeholders
with the required resources (e.g. equipment, knowledge, time) to perform an attack. In a real system,
risk assessment is based on the evaluation of the costs and benefits of each countermeasure.
— No specific system design or configuration was deemed as universally applicable. Only the available
EFC base standards were taken as references. Specific technical details of a particular system
(e.g. servers, computer centres, and de-centralised elements like roadside equipment) need to be
additionally taken into consideration when implementing security measures.
vi © ISO 2020 – All rights reserved
---------------------- Page: 6 ----------------------
ISO 19299:2020(E)
Selection of requirements and respective security measures for an existing EFC system is based on the
security policy and the risk assessment of several stakeholders’ systems. Due to the fact that there is
no overall valid security policy, nor is there the possibility to provide a useful risk assessment, the EFC
security framework provides an extensive (but non-exhaustive) toolbox of requirements and security
measures.
To understand the content of this document, the reader should be aware of the methodological
assumptions used to develop it. Security of an (interoperable) EFC scheme depends on the correct
implementation and operation of a number of processes, systems, and interfaces. Only a reliable end-to-
end security ensures the accurate and trustworthy operation of interacting components of toll charging
environments. Therefore, this security framework also covers systems or interfaces which are not EFC
specific, like back office connections. An application independent security framework for such system
parts and interfaces, an information security management system (ISMS), can be found, for example, in
the ISO/IEC 27000 series.
The development process of this document is described briefly in the steps below:
a) Definition of the stakeholder objectives and generic requirements as the basic motivation for the
security requirements (Annex C). A possible security policy with a set of policy statements is
provided in Annex E, and an example of a European electronic toll service (EETS) security policy is
given in Annex F.
b) Based on the EFC role model and further definitions from the EFC architecture standard
(ISO 17573-1), the specification defines an abstract EFC system model as the basis for a threat
analysis, definition of requirements, and security measures.
c) The threats on the EFC system model and its assets are analysed by two different methods: an
attack-based analysis and an asset-based analysis. The first approach considers several threat
scenarios from the perspective of various attackers. The second approach looks in depth on threats
against the various identified assets (tangible and intangible). This approach, although producing
some redundancy, ensures completeness and coverage of a broad range of risks (see Annex D).
d) The requirements specification (see Clause 6) is based on the threats identified in Annex D.
Each requirement is at least motivated by one threat and each threat is covered by at least one
requirement.
e) The definition of security measures (see Clause 7) provides a high-level description of recommended
possible methods to cover the developed requirements.
f) The security specifications for interoperable interface implementation (Clause 8) provide detailed
definitions, such as for message authenticators. These specifications represent an add-on for
security to the corresponding relevant interface standards.
g) Basic key management requirements that support the implementation of the interoperable
interfaces are described in Clause 9. The toll charging environment uses cryptographic elements
(e.g. keys, certificates, certificate revocation lists) to support security services like confidentiality,
integrity, authenticity, and non-repudiation. This section of the document covers the (initial) setup
of key exchange between stakeholders and several operational procedures, such as key renewal,
certificate revocation.
h) A general trust model (see Clause 5) is defined to form the basis for the implementation of
cryptographic procedures to ensure confidentiality, integrity, and authenticity of exchanged
data. In this context, the security framework references approved international standards for the
implementation of cryptographic procedures enhanced by EFC specific details where needed.
A stakeholder of an EFC scheme who wants to use this security framework should to do the following:
— define a security policy for the EFC scheme (may involve more than one stakeholder in an interoperable
EFC scheme). Some examples for a security policy and its elements are provided (in Annex E and
Annex F) as an aid to build up a secure system for a concrete interoperability framework (including
the European electronic toll service).
© ISO 2020 – All rights reserved vii
---------------------- Page: 7 ----------------------
ISO 19299:2020(E)
— identify the relevant processes, systems and interfaces, and match them to the EFC security
framework;
— select the corresponding security requirements according to the security policy;
— implement the security measures associated to the selected requirements;
— provide evidence of compliance of its systems, processes, and interfaces with the requirements
of this document. Evidence can be provided by a self-declaration, an internal or external audit, or
other certifications.
EFC role model
This document complies with the role model defined in ISO 17573-1. According to this role model, the
toll charger (TC) manages the tolled infrastructure or transport service and is the recipient of the road
usage fees. The TC is the actor associated with the toll charging role (see Figure 2).
Figure 2 — Role model underlying this document
Toll service providers (TSPs) act as intermediaries between TC’s and road users, by providing these
latter with contractual relationships and devices (generally on-board equipment — OBE) to interface
the tolled infrastructure or transport service. The OBE will be used for collecting data, enabling the TC
to send a claim to the TSP for the use of the infrastructure or transport service by their service users
(SU). In autonomous systems, each TSP delivers toll declarations to the TC who operates the autonomous
system. In dedicated short-range communication (DSRC)-based systems, the TC receives the main
toll declarations from its own RSE which communicates with the TSP’s OBE. The interoperability
management role (IM) in Figure 2 comprises all specifications and activities that define and maintain a
set of rules that govern the overall toll charging environment.
The trust model defined in this document is based on the role model summarized above and it is also
the technical base for the protection of the data communication between the entities of the role model.
Besides this communication, security, trust in the secure implementation and management of the back
end and other equipment for the EFC framework is essential. A TC or TSP compliant to this document
should be able to give evidence of security management as required. Such evidence is the basis of trust
relations between the involved entities.
Figure 3 below illustrates the abstract EFC system model used to analyse the threats and define the
security requirements and associated security measures for this document. This document assumes
an OBE that is dedicated to EFC purposes only and does not consider value added services based on
EFC OBE, nor does it consider more generic OBE platforms (also called in-vehicle ITS Stations) which
could be used to host the EFC application. The OBE may either be connected to a central account or use
a payment medium such as integrated circuit cards (ICC) or mobile payment for on-board-account EFC
system. Any financial transactions are out of scope of this document.
viii © ISO 2020 – All rights reserved
---------------------- Page: 8 ----------------------
ISO 19299:2020(E)
Figure 3 — EFC system model of the EFC security framework
Relation to other security standards
Several generic and specific standards and technical reports concerning security issues for information
technology already exist. This document makes use of existing standards and expands their usability
for EFC applications. This framework references and adapts security techniques and methodologies
from relevant standards.
Figure 4 shows the context of the EFC security framework to the most relevant security standards that
gave input to this document. Standards that are directly used and referenced are highlighted in black.
© ISO 2020 – All rights reserved ix
---------------------- Page: 9 ----------------------
ISO 19299:2020(E)
Figure 4 — Relevant security standards in the context of the EFC — Security framework
Standards shown in Figure 4 are grouped in the following categories, where arrows inside each group
indicate which standard provides input to other standards:
— Security techniques — Security measures and algorithms: collection of essential security
measures and recommended cryptographic algorithms including the guidelines for accurate use.
— IT — Open system interconnection: provides mechanisms for the secure communications
between open systems. These standards address some of the security requirements in the areas of
authentication and other security services through the provision of a set of frameworks.
— Evaluation criteria for IT security (common criteria): defines methodologies and processes
for the security evaluation and certification for most categories of products used in the EFC
environment.
— IT — Security techniques — Information security management system: defines requirements
and guidelines for the implementation of security management systems for all types of organizations.
The standards in this group are suited for security solutions of back end and other fixed or installed
equipment of EFC systems, including their software.
An ISO/IEC 27001 certification of a TC or TSP organization may be used to demonstrate conformity
with this document, provided that the scope and the Statements of Applicability (SoA) include the
EFC business processes specified in ISO 17573-1 and that security requirements and their associated
security measures provided by this document are applied, for example by
...
NORME ISO
INTERNATIONALE 19299
Première édition
2020-08
Perception de télépéage — Cadre de
sécurité
Electronic fee collection — Security framework
Numéro de référence
ISO 19299:2020(F)
©
ISO 2020
---------------------- Page: 1 ----------------------
ISO 19299:2020(F)
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2020
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, 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, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2020 – Tous droits réservés
---------------------- Page: 2 ----------------------
ISO 19299:2020(F)
Sommaire Page
Avant-propos .v
Introduction .vi
1 Domaine d’application . 1
2 Références normatives . 1
3 Termes et définitions . 2
4 Termes abrégés . 3
5 Modèle de confiance . 5
5.1 Vue d’ensemble . 5
5.2 Relations de confiance entre les parties prenantes . 5
5.3 Modèle de confiance technique . 6
5.3.1 Généralités . 6
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) . 6
5.3.3 Modèle de confiance pour les relations entre le prestataire de services de
péage (TSP) et l’utilisateur du service (SU) . 7
5.3.4 Modèle de confiance pour les relations du gestionnaire de
l’interopérabilité (IM) . 8
5.4 Mise en œuvre. 8
5.4.1 Instauration des relations de confiance . 8
5.4.2 Renouvellement et révocation des relations de confiance . 9
5.4.3 Émission et révocation des certificats de l’autorité de certification (CA)
subordonnée et d’entité finale . 9
5.4.4 Profil et format de certificat et de liste de révocation de certificats (CRL) .10
5.4.5 Extensions de certificat .10
6 Exigences relatives à la sécurité .11
6.1 Généralités .11
6.2 Système de management de la sécurité de l’information (ISMS) .12
6.3 Interfaces de communication .13
6.4 Stockage des données .13
6.5 Percepteur de péage .14
6.6 Prestataire de services de péage .16
6.7 Gestionnaire de l’interopérabilité (IM) .18
6.8 Limitation des exigences .19
7 Mesures de sécurité — Contre-mesures .19
7.1 Vue d’ensemble .19
7.2 Mesures de sécurité générales .19
7.3 Mesures de sécurité relatives aux interfaces de communication .20
7.3.1 Généralités .20
7.3.2 Interface DSRC-EFC .21
7.3.3 Interface CCC .22
7.3.4 Interface LAC .23
7.3.5 Interface entre le système frontal et le système dorsal du prestataire de
services de péage (TSP) .23
7.3.6 Interface entre le TC et le TSP .24
7.3.7 Interface ICC.25
7.4 Mesures de sécurité de bout en bout .26
7.5 Mesures de sécurité relatives au prestataire de services de péage (TSP) .28
7.5.1 Mesures de sécurité relatives au système frontal .28
7.5.2 Mesures de sécurité relatives au système dorsal . .28
7.6 Mesures de sécurité relatives au percepteur de péage (TC) .29
7.6.1 Mesures de sécurité relatives à l’équipement au sol (RSE) .29
7.6.2 Mesures de sécurité relatives au système dorsal . .30
© ISO 2020 – Tous droits réservés iii
---------------------- Page: 3 ----------------------
ISO 19299:2020(F)
7.6.3 Autres mesures de sécurité relatives au percepteur de péage (TC) .31
8 Spécifications de sécurité relatives à la mise en œuvre d’une interface interopérable .31
8.1 Généralités .31
8.1.1 Sujet .31
8.1.2 Signature et algorithmes de hachage .31
8.2 Spécifications de sécurité relatives à l’interface DSRC-EFC .31
8.2.1 Sujet .31
8.2.2 OBE .31
8.2.3 RSE .32
9 Gestion de clés .32
9.1 Vue d’ensemble .32
9.2 Clés asymétriques .32
9.2.1 Échange de clés entre les parties prenantes .32
9.2.2 Génération et certification de clés .32
9.2.3 Protection des clés .33
9.2.4 Application .33
9.3 Clés symétriques .33
9.3.1 Généralités .33
9.3.2 Échange de clés entre les parties prenantes .34
9.3.3 Cycle de vie des clés .34
9.3.4 Stockage et protection de clé .36
9.3.5 Clés de session .36
Annexe A (normative) Profils de sécurité .37
Annexe B (normative) Formulaire de déclaration de conformité de mise en œuvre (ICS) .42
Annexe C (informative) Objectifs des parties prenantes et exigences génériques .61
Annexe D (informative) Analyse des menaces .66
Annexe E (informative) Politiques de sécurité .132
Annexe F (informative) Exemple de politique de sécurité d’un service européen de
télépéage (SET) .139
Annexe G (informative) Recommandations relatives à une mise en œuvre axée sur la vie
privée .141
Bibliographie .143
iv © ISO 2020 – Tous droits réservés
---------------------- Page: 4 ----------------------
ISO 19299:2020(F)
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 attiré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 nature volontaire des normes, 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’Organisation mondiale du commerce (OMC) concernant les obstacles
techniques au commerce (OTC), voir www .iso .org/ avant -propos.
Le présent document a été élaboré par le comité technique ISO/TC 204, Systèmes de transport intelligents,
en collaboration avec le comité technique CEN/TC 278, Systèmes de transport intelligents, du Comité
européen de normalisation (CEN) conformément à l’Accord de coopération technique entre l’ISO et le
CEN (Accord de Vienne).
Cette première édition annule et remplace la première édition de l’ISO/TS 19299:2015 qui a fait l’objet
d’une révision technique.
Les principales modifications par rapport à l’édition précédente sont les suivantes:
— exigences et mesures de sécurité ajoutées pour l’utilisation de moyens de paiement communs selon
l’ISO/TS 21193;
— mise à jour des considérations relatives à la protection des données en Annexe G, afin de prendre
en compte le nouveau règlement général sur la protection des données (Directive 2016/679/CE) de
l’Union européenne.
Il convient que l’utilisateur adresse tout retour d’information ou toute question concernant le présent
document à l’organisme national de normalisation de son pays. Une liste exhaustive desdits organismes
se trouve à l’adresse www .iso .org/ fr/ members .html.
© ISO 2020 – Tous droits réservés v
---------------------- Page: 5 ----------------------
ISO 19299:2020(F)
Introduction
Contexte du présent document
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 (voir Figure 1):
— 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é.
Figure 1 — Plan de développement des documents de sécurité
Chaque acteur d’un système EFC existant mets en œuvre les mesures de sécurité définies et supervise
leur efficacité. Lorsqu'une mesure de sécurité ne fonctionne pas correctement, un processus
d'amélioration est lancé. Le développement du cadre de sécurité EFC s’attache à suivre cette approche
avec les limitations suivantes:
— Il n’existe aucune politique standard de sécurité et elle ne peut pas non plus être définie: la politique
de sécurité peut seulement être définie par les parties prenantes responsables, et son rayon d’action
est limité par la réglementation et les lois applicables. Néanmoins, le présent document propose
quelques exemples simples des politiques de sécurité possibles (de l’Annexe E à l’Annexe F).
— Aucune évaluation standard des risques n’est possible: l’évaluation des risques compare la perte
possible pour la partie prenante avec les ressources nécessaires (par exemple équipement,
connaissances, temps) à la réalisation d’une attaque. Dans un système réel, l’évaluation des risques
repose sur l’évaluation des coûts et des avantages de chaque contre-mesure.
vi © ISO 2020 – Tous droits réservés
---------------------- Page: 6 ----------------------
ISO 19299:2020(F)
— Aucune conception ou configuration de système spécifique n’a été jugée universellement applicable.
Seules les normes EFC de base disponibles ont été prises comme références. 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 des mesures de sécurité.
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.
Étant 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, le cadre de sécurité EFC propose un ensemble complet (mais non exhaustif)
d’exigences et de mesures de sécurité.
Pour comprendre le contenu du présent document, 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é fiable de bout en bout garantit le fonctionnement précis et fiable des
composants d’interaction des environnements de perception du télé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. Un cadre de sécurité indépendant de l’application pour ces
parties et interfaces, un système de management de la sécurité de l’information (ISMS, Information
Security Management System), peut être trouvé, par exemple, dans la série de normes ISO/IEC 27000.
Le processus d’élaboration du présent document 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-1), 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 de menace du point de vue des agresseurs. La seconde
approche étudie de manière approfondie les menaces à l’égard des différents actifs identifiés
(corporels et incorporels). Cette approche, même si elle introduit une certaine redondance, garantit
l’exhaustivité et la couverture d’un vaste éventail 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, tel que 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 télépéage utilise des
éléments cryptographiques (par exemple clés, certificats, liste de révocation de certificats) 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 du document 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.
© ISO 2020 – Tous droits réservés vii
---------------------- Page: 7 ----------------------
ISO 19299:2020(F)
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é devrait 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 à la conception d’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 le présent document. La preuve peut être une autodéclaration, un audit interne ou externe,
voire d’autres certifications.
Modèle de rôle EFC
Le présent document satisfait au modèle de rôle défini dans l’ISO 17573-1. Selon ce modèle de rôle, le
percepteur de péage (TC, Toll Charger) gère l’infrastructure de péage ou du service de transport et
est le destinataire des redevances du réseau routier. Le TC est l’acteur associé au rôle Perception du
télépéage (voir Figure 2).
Figure 2 — Modèle de rôle sous-tendant le présent document
Les prestataires de services de péage (TSPs, Toll Service Providers) agissent en tant qu'intermédiaire
entre les TC et les usagers de la route, en fournissant à ces derniers des relations contractuelles et des
dispositifs (généralement des équipements embarqués (OBE, On-Board Equipment) pour interfacer le
service d’infrastructure ou de transport à péage. L’OBE 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. 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 les OBE du TSP. Le rôle de gestionnaire de l’interopérabilité (IM, Interoperability
viii © ISO 2020 – Tous droits réservés
---------------------- Page: 8 ----------------------
ISO 19299:2020(F)
Management) représentée à la Figure 2 inclut toutes les spécifications et activités qui définissent et
maintiennent un ensemble de règles gouvernant l’environnement global de perception du télépéage.
Le modèle de confiance défini dans le présent document est basé sur le modèle de rôle résumé 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 sont essentiels. Un
percepteur de péage (TC) ou un prestataire de services de péage (TSP) en conformité avec le présent
document devrait être capable de fournir une preuve du management de la sécurité exigée. 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 décrit les exigences de sécurité et des mesures de sécurité associées pour le présent document.
Ce document suppose qu’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, et ne considère pas non plus que les plateformes OBE
plus génériques (également appelées « stations STI embarquées ») pourraient être 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ère
...
FINAL
INTERNATIONAL ISO/FDIS
DRAFT
STANDARD 19299
ISO/TC 204
Electronic fee collection — Security
Secretariat: ANSI
framework
Voting begins on:
20200514
Perception de télépéage — Cadre de sécurité
Voting terminates on:
20200709
ISO/CEN PARALLEL PROCESSING
RECIPIENTS OF THIS DRAFT ARE INVITED TO
SUBMIT, WITH THEIR COMMENTS, NOTIFICATION
OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPOR TING
DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
Reference number
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO
ISO/FDIS 19299:2020(E)
LOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON
OCCASION HAVE TO BE CONSIDERED IN THE
LIGHT OF THEIR POTENTIAL TO BECOME STAN
DARDS TO WHICH REFERENCE MAY BE MADE IN
©
NATIONAL REGULATIONS. ISO 2020
---------------------- Page: 1 ----------------------
ISO/FDIS 19299:2020(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO 2020
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH1214 Vernier, Geneva
Phone: +41 22 749 01 11
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2020 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/FDIS 19299:2020(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 3
5 Trust model . 4
5.1 Overview . 4
5.2 Stakeholders trust relations . 5
5.3 Technical trust model . 6
5.3.1 General. 6
5.3.2 Trust model for TC and TSP relations . 6
5.3.3 Trust model for TSP and service user relations . 7
5.3.4 Trust model for interoperability management relations . 7
5.4 Implementation . 7
5.4.1 Setup of trust relations . 7
5.4.2 Trust relation renewal and revocation . 8
5.4.3 Issuing and revocation of sub CA and end-entity certificates . 8
5.4.4 Certificate and certificate revocation list profile and format . 9
5.4.5 Certificate extensions . 9
6 Security requirements .10
6.1 General .10
6.2 Information security management system .11
6.3 Communication interfaces .12
6.4 Data storage .12
6.5 Toll charger .12
6.6 Toll service provider .14
6.7 Interoperability management .16
6.8 Limitation of requirements .17
7 Security measures — Countermeasures .17
7.1 Overview .17
7.2 General security measures .18
7.3 Communication interfaces security measures .18
7.3.1 General.18
7.3.2 DSRCEFC interface . .19
7.3.3 CCC interface .20
7.3.4 LAC interface .21
7.3.5 Front End to TSP back end interface .21
7.3.6 TC to TSP interface .22
7.3.7 ICC interface .23
7.4 End-to-end security measures .24
7.5 Toll service provider security measures .25
7.5.1 Front end security measures .25
7.5.2 Back end security measures .26
7.6 Toll charger security measures .27
7.6.1 RSE security measures . .27
7.6.2 Back end security measures .28
7.6.3 Other TC security measures .28
8 Security specifications for interoperable interface implementation .29
8.1 General .29
8.1.1 Subject.29
© ISO 2020 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/FDIS 19299:2020(E)
8.1.2 Signature and hash algorithms .29
8.2 Security specifications for DSRC-EFC .29
8.2.1 Subject.29
8.2.2 OBE .29
8.2.3 RSE .29
9 Key management .30
9.1 Overview .30
9.2 Asymmetric keys .30
9.2.1 Key exchange between stakeholders .30
9.2.2 Key generation and certification .30
9.2.3 Protection of keys .30
9.2.4 Application .31
9.3 Symmetric keys .31
9.3.1 General.31
9.3.2 Key exchange between stakeholders .31
9.3.3 Key lifecycle .32
9.3.4 Key storage and protection .33
9.3.5 Session keys .34
Annex A (normative) Security profiles .35
Annex B (informative) Implementation conformance statement (ICS) proforma .39
Annex C (informative) Stakeholder objectives and generic requirements .57
Annex D (informative) Threat analysis .61
Annex E (informative) Security policies .118
Annex F (informative) Example for an EETS security policy .124
Annex G (informative) Recommendations for privacy-focused implementation .126
Bibliography .128
iv © ISO 2020 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/FDIS 19299:2020(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and nongovernmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www .iso .org/ directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to the
World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT) see www .iso .org/
iso/ foreword .html.
This document was prepared by Technical Committee ISO/TC 278, Intelligent transport systems, in
collaboration with the European Committee for Standardization (CEN) Technical Committee CEN/
TC 251 Intelligent transport systems (ITS), in accordance with the Agreement on technical cooperation
between ISO and CEN (Vienna Agreement).
This first edition cancels and replaces the first edition of ISO/TS 19299:2015, which has been technically
revised.
The main changes compared to the previous edition are as follows:
— added requirements and security measures for the use of common payment media according to
ISO/TS 21193;
— updated data protection considerations in Annex G, in order to take into account the European
Union’s new General Data Protection Regulation (i.e. Directive 2016/679/EC).
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www .iso .org/ members .html.
© ISO 2020 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/FDIS 19299:2020(E)
Introduction
Context of this document
The development process for a security concept and implementation to protect any existing electronic
fee collection (EFC) system normally includes several steps as follows (see Figure 1):
— definition of the security objectives and policy statements in a security policy;
— threat analysis with risk assessment to define the security requirements;
— development of the security measures followed by the development of security test specifications.
Figure 1 — Development path for the security documents
Each actor in an existing EFC system implements the defined security measures and supervises their
effectiveness. When a security measure is found not working properly, an improvement process is
started. The development of the EFC security framework follows this approach, with the following
limitations:
— No standard security policy exists, nor can it be defined: The security policy can only be defined by
the responsible stakeholders and it is limited by laws and regulations. Nonetheless, this document
provides basic examples of possible security policies (in Annex E to Annex F).
— No standard risk assessment is possible: Risk assessment compares possible losses to stakeholders
with the required resources (e.g. equipment, knowledge, time) to perform an attack. In a real system,
risk assessment is based on the evaluation of the costs and benefits of each countermeasure.
— No specific system design or configuration was deemed as universally applicable. Only the available
EFC base standards were taken as references. Specific technical details of a particular system
(e.g. servers, computer centres, and de-centralised elements like roadside equipment) need to be
additionally taken into consideration when implementing security measures.
vi © ISO 2020 – All rights reserved
---------------------- Page: 6 ----------------------
ISO/FDIS 19299:2020(E)
Selection of requirements and respective security measures for an existing EFC system is based on the
security policy and the risk assessment of several stakeholders’ systems. Due to the fact that there is
no overall valid security policy, nor is there the possibility to provide a useful risk assessment, the EFC
security framework provides an extensive (but non-exhaustive) toolbox of requirements and security
measures.
To understand the content of this document, the reader should be aware of the methodological
assumptions used to develop it. Security of an (interoperable) EFC scheme depends on the correct
implementation and operation of a number of processes, systems, and interfaces. Only a reliable end-to-
end security ensures the accurate and trustworthy operation of interacting components of toll charging
environments. Therefore, this security framework also covers systems or interfaces which are not EFC
specific, like back office connections. An application independent security framework for such system
parts and interfaces, an information security management system (ISMS), can be found, for example, in
the ISO/IEC 27000 series.
The development process of this document is described briefly in the steps below:
a) Definition of the stakeholder objectives and generic requirements as the basic motivation for the
security requirements (Annex C). A possible security policy with a set of policy statements is
provided in Annex E, and an example of a European electronic toll service (EETS) security policy is
given in Annex F.
b) Based on the EFC role model and further definitions from the EFC architecture standard
(ISO 17573-1), the specification defines an abstract EFC system model as the basis for a threat
analysis, definition of requirements, and security measures.
c) The threats on the EFC system model and its assets are analysed by two different methods: an
attack-based analysis and an asset-based analysis. The first approach considers several threat
scenarios from the perspective of various attackers. The second approach looks in depth on threats
against the various identified assets (tangible and intangible). This approach, although producing
some redundancy, ensures completeness and coverage of a broad range of risks (see Annex D).
d) The requirements specification (see Clause 6) is based on the threats identified in Annex D.
Each requirement is at least motivated by one threat and each threat is covered by at least one
requirement.
e) The definition of security measures (see Clause 7) provides a highlevel description of recommended
possible methods to cover the developed requirements.
f) The security specifications for interoperable interface implementation (Clause 8) provide detailed
definitions, such as for message authenticators. These specifications represent an add-on for
security to the corresponding relevant interface standards.
g) Basic key management requirements that support the implementation of the interoperable
interfaces are described in Clause 9. The toll charging environment uses cryptographic elements
(e.g. keys, certificates, certificate revocation lists) to support security services like confidentiality,
integrity, authenticity, and non-repudiation. This section of the document covers the (initial) setup
of key exchange between stakeholders and several operational procedures, such as key renewal,
certificate revocation.
h) A general trust model (see Clause 5) is defined to form the basis for the implementation of
cryptographic procedures to ensure confidentiality, integrity, and authenticity of exchanged
data. In this context, the security framework references approved international standards for the
implementation of cryptographic procedures enhanced by EFC specific details where needed.
A stakeholder of an EFC scheme who wants to use this security framework should to do the following:
— define a security policy for the EFC scheme (may involve more than one stakeholder in an interoperable
EFC scheme). Some examples for a security policy and its elements are provided (in Annex E and
Annex F) as an aid to build up a secure system for a concrete interoperability framework (including
the European electronic toll service).
© ISO 2020 – All rights reserved vii
---------------------- Page: 7 ----------------------
ISO/FDIS 19299:2020(E)
— identify the relevant processes, systems and interfaces, and match them to the EFC security
framework;
— select the corresponding security requirements according to the security policy;
— implement the security measures associated to the selected requirements;
— provide evidence of compliance of its systems, processes, and interfaces with the requirements
of this document. Evidence can be provided by a self-declaration, an internal or external audit, or
other certifications.
EFC role model
This document complies with the role model defined in ISO 17573-1. According to this role model, the
toll charger (TC) manages the tolled infrastructure or transport service and is the recipient of the road
usage fees. The TC is the actor associated with the toll charging role (see Figure 2).
Figure 2 — Role model underlying this document
Toll service providers (TSPs) act as intermediaries between TC’s and road users, by providing these
latter with contractual relationships and devices (generally on-board equipment — OBE) to interface
the tolled infrastructure or transport service. The OBE will be used for collecting data, enabling the TC
to send a claim to the TSP for the use of the infrastructure or transport service by their service users
(SU). In autonomous systems, each TSP delivers toll declarations to the TC who operates the autonomous
system. In dedicated short-range communication (DSRC)-based systems, the TC receives the main
toll declarations from its own RSE which communicates with the TSP’s OBE. The interoperability
management role (IM) in Figure 2 comprises all specifications and activities that define and maintain a
set of rules that govern the overall toll charging environment.
The trust model defined in this document is based on the role model summarized above and it is also
the technical base for the protection of the data communication between the entities of the role model.
Besides this communication, security, trust in the secure implementation and management of the back
end and other equipment for the EFC framework is essential. A TC or TSP compliant to this document
should be able to give evidence of security management as required. Such evidence is the basis of trust
relations between the involved entities.
Figure 3 below illustrates the abstract EFC system model used to analyse the threats and define the
security requirements and associated security measures for this document. This document assumes
an OBE that is dedicated to EFC purposes only and does not consider value added services based on
EFC OBE, nor does it consider more generic OBE platforms (also called invehicle ITS Stations) which
could be used to host the EFC application. The OBE may either be connected to a central account or use
a payment medium such as integrated circuit cards (ICC) or mobile payment for on-board-account EFC
system. Any financial transactions are out of scope of this document.
viii © ISO 2020 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/FDIS 19299:2020(E)
Figure 3 — EFC system model of the EFC security framework
Relation to other security standards
Several generic and specific standards and technical reports concerning security issues for information
technology already exist. This document makes use of existing standards and expands their usability
for EFC applications. This framework references and adapts security techniques and methodologies
from relevant standards.
Figure 4 shows the context of the EFC security framework to the most relevant security standards that
gave input to this document. Standards that are directly used and referenced are highlighted in black.
© ISO 2020 – All rights reserved ix
---------------------- Page: 9 ----------------------
ISO/FDIS 19299:2020(E)
Figure 4 — Relevant security standards in the context of the EFC — Security framework
Standards shown in Figure 4 are grouped in the following categories, where arrows inside each group
indicate which standard provides input to other standards:
— Security techniques — Security measures and algorithms: collection of essential security
measures and recommended cryptographic algorithms including the guidelines for accurate use.
— IT — Open system interconnection: provides mechanisms for the secure communications
between open systems. These standards address some of the security requirements in the areas of
authentication and other security services through the provision of a set of frameworks.
— Evaluation criteria for IT security (common criteria): defines methodologies and processes
for the security evaluation and certification for most categories of products used in the EFC
environment.
— IT — Security techni
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.