ISO/TS 17574:2017
(Main)Electronic fee collection — Guidelines for security protection profiles
Electronic fee collection — Guidelines for security protection profiles
ISO/TS 17574:2017 provides guidelines for preparation and evaluation of security requirements specifications, referred to as Protection Profiles (PP) in ISO/IEC 15408 (all parts) and in ISO/IEC TR 15446. By Protection Profile (PP), it means a set of security requirements for a category of products or systems that meet specific needs. A typical example would be a PP for On-Board Equipment (OBE) to be used in an EFC system. However, the guidelines in this document are superseded if a Protection Profile already exists for the subsystem in consideration.
Perception de télépéage — Lignes directrices concernant les profils de protection de la sécurité
General Information
Relations
Standards Content (Sample)
TECHNICAL ISO/TS
SPECIFICATION 17574
Third edition
2017-03
Electronic fee collection — Guidelines
for security protection profiles
Perception de télépéage — Lignes directrices concernant les profils de
protection de la sécurité
Reference number
©
ISO 2017
© ISO 2017, Published in Switzerland
All rights reserved. Unless otherwise specified, 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
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 2017 – All rights reserved
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 2
4 Abbreviated terms . 4
5 EFC security architecture and protection profile processes . 5
5.1 General . 5
5.2 EFC security architecture . 5
5.3 Protection profile preparatory steps . 6
5.4 Relationship between actors. 7
6 Outlines of Protection Profile . 9
6.1 Structure . 9
6.2 Context .10
Annex A (informative) Procedures for preparing documents .11
Annex B (informative) Example of threat analysis evaluation method .45
Annex C (informative) Relevant security standards in the context of the EFC .50
Annex D (informative) Common Criteria Recognition Arrangement (CCRA).51
Bibliography .52
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 on 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 the following URL: www . i so .org/ iso/ foreword .html.
The committee responsible for this document is ISO/TC 204, Intelligent transport systems.
This third edition cancels and replaces the second edition (ISO/TS 17574:2009), which has been
technically revised. This edition includes the following significant changes with respect to the previous
edition:
— Clause 1 has been redrafted and shortened;
— Clause 3 has been updated with harmonized terms;
— requirements updated as to reflect the latest version of the ISO/IEC 15408 series;
— a new Clause 5 has been added, comprising much of the text from the Scope of the previous
edition.
iv © ISO 2017 – All rights reserved
Introduction
Electronic fee collection (EFC) systems are subject to several ways of fraud both by users and operators
but also from people outside the system. These security threats have to be met by different types of
security measures including security requirements specifications.
It is recommended that EFC operators or national organizations, e.g. highway authorities or transport
ministries, use the guideline provided by this document to prepare their own EFC/protection profile
(PP), as security requirements should be described from the standpoint of the operators and/or
operators’ organizations.
It should be noted that this document is of a more informative than normative nature and it is intended
to be read in conjunction with the underlying international standards ISO/IEC 15408 (all parts).
Most of the content of this document is an example shown in Annex A on how to prepare the security
requirements for EFC equipment, in this case, a DSRC-based OBE with an IC card loaded with crucial
data needed for the EFC. The example refers to a Japanese national EFC system and should only be
regarded as an example.
After an EFC/PP is prepared, it can be internationally registered by the organization that prepared the
EFC/PP so that other operators or countries that want to develop their EFC system security services
can refer to an already registered EFC/PP.
This EFC-related document on security service framework and EFC/PP is based on ISO/IEC 15408 (all
parts). ISO/IEC 15408 (all parts) includes a set of requirements for the security functions and assurance
of IT-relevant products and systems. Operators, organizations or authorities defining their own EFC/PP
can use these requirements. This will be similar to the different PPs registered by several financial
institutions, e.g. for payment instruments like IC cards.
The products and systems that were developed in accordance with ISO/IEC 15408 (all parts) can be
publicly assured by the authentication of the government or designated private evaluation agencies.
TECHNICAL SPECIFICATION ISO/TS 17574:2017(E)
Electronic fee collection — Guidelines for security
protection profiles
1 Scope
This document provides guidelines for preparation and evaluation of security requirements
specifications, referred to as Protection Profiles (PP) in ISO/IEC 15408 (all parts) and in
ISO/IEC TR 15446.
By Protection Profile (PP), it means a set of security requirements for a category of products or systems
that meet specific needs. A typical example would be a PP for On-Board Equipment (OBE) to be used in
an EFC system. However, the guidelines in this document are superseded if a Protection Profile already
exists for the subsystem in consideration.
The target of evaluation (TOE) for EFC is limited to EFC specific roles and interfaces as shown in
Figure 1. Since the existing financial security standards and criteria are applicable to other external
roles and interfaces, they are assumed to be outside the scope of TOE for EFC.
Figure 1 — Scope of TOE for EFC
The security evaluation is performed by assessing the security-related properties of roles, entities and
interfaces defined in security targets (STs), as opposed to assessing complete processes which often are
distributed over more entities and interfaces than those covered by the TOE of this document.
NOTE Assessing security issues for complete processes is a complimentary approach, which may well be
beneficial to apply when evaluating the security of a system.
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http:// www .electropedia .org/
— ISO Online browsing platform: available at http:// www .iso .org/ obp
3.1
assurance requirement
security requirements to assure confidence in the implementation of functional requirements
3.2
audit
independent review and examination in order to ensure compliance with established policy and
operational procedures and to recommend associated changes
3.3
availability
property of being accessible and usable upon demand by an authorized entity
[SOURCE: ISO/TS 19299:2015, 3.6]
3.4
certification
procedure by which a party gives written assurance that a product, process, or service conforms to
specified requirements
[SOURCE: ISO/TS 14907-1:2015, 3.3]
3.5
confidentiality
prevention of information leakage to non-authenticated individuals, parties, and/or processes
[SOURCE: ISO/TS 19299:2015, 3.11]
3.6
data privacy
rights and obligations of individuals and organizations with respect to the collection, use, retention,
disclosure and disposal of personal information
[SOURCE: ISO/TS 19299:2015, 3.32]
3.7
Evaluation Assurance Level
EAL
set of assurance requirements, usually involving documentation, analysis and testing, representing a
point on a predefined assurance scale, that form an assurance package
3.8
functional requirement
requirement for a function that a system or system component is able to perform
3.9
integrity
property that data have not been altered or destroyed in an unauthorized manner
3.10
international registrar
organization authorized to register protection profiles at an international level
2 © ISO 2017 – All rights reserved
3.11
key management
generation, distribution, storage, application and revocation of encryption keys
3.12
On-Board Equipment
OBE
required equipment on-board a vehicle for performing required EFC functions and communication
services
Note 1 to entry: The OBE does not need to include payment means.
3.13
personalization card
set-up card
IC card to transcribe individual data such as vehicle information into On-Board Equipment
3.14
rationale verification
process determining that a product of each phase of the system lifecycle development process fulfils all
the requirements specified in the previous phase
3.15
reliability
ability of a device or a system to perform its intended function under given conditions of use for a
specified period of time or number of cycles
[SOURCE: ISO/TS 14907-1:2015, 3.17]
3.16
road side equipment
RSE
equipment located along the road, either fixed or mobile
3.17
secure application module
SAM
physical module that securely executes cryptographic functions and stores keys
[SOURCE: ISO/TS 19299:2015, 3.35]
3.18
security policy
set of rules that regulate how to handle security threats or define the appropriate security level
[SOURCE: ISO/TS 19299:2015, 3.36]
3.19
security target
ST
set of security requirements and specifications to be used as the basis for evaluation of an identified TOE
3.20
security threat
potential action or manner to violate the security of a system
3.21
target of evaluation
TOE
set of software, firmware and/or hardware possibly accompanied by guidance
[SOURCE: ISO/IEC 15408-1:2009, 3.1.70]
3.22
threat agent
entity that has the intention to act adversely on an asset
[SOURCE: ISO/TS 19299:2015, 3.40]
3.23
toll charger
entity which levies toll for the use of vehicles in a toll domain
Note 1 to entry: In other documents, the terms operator or toll operator can be used.
[SOURCE: ISO 17573:2010, 3.16, modified]
3.24
toll service provider
TSP
entity providing toll services in one or more toll domains
Note 1 to entry: In other documents, the terms issuer or contract issuer might be used.
Note 2 to entry: The toll service provider can provide the OBE or might provide only a magnetic card or a smart
card to be used with an OBE provided by a third party (like a mobile telephone and a SIM card can be obtained
from different parties).
Note 3 to entry: The toll service provider is responsible for the operation (functioning) of the OBE.
[SOURCE: ISO 17573:2010, 3.23, modified]
4 Abbreviated terms
CC Common Criteria
CCRA Common Criteria Recognition Arrangement
CN cellular networks
DSRC dedicated short-range communication
EAL Evaluation Assurance Level
EFC electronic fee collection
GNSS global navigation satellite systems
HMI human machine interface
I/F interface
ICC integrated circuit(s) card
IT information technology
OBE On-Board Equipment
PP Protection Profile
RSE road side equipment
SAM secure application module
4 © ISO 2017 – All rights reserved
SFP security function policy
SOF strength of function
ST security target
TOE target of evaluation
TSF TOE security functions
5 EFC security architecture and protection profile processes
5.1 General
This clause gives an overview of the context and use of this document in terms of the EFC security
architecture and protection profile processes.
This document is intended to be read in conjunction with the underlying standards ISO/IEC 15408 (all
parts) and ISO/IEC TR 15446. Although a layman could read the first part of the document to have an
overview on how to prepare a Protection Profile for EFC equipment, the annexes, particularly A.4 and
A.5, require that the reader be familiar with ISO/IEC 15408 (all parts). The document uses an OBE with
an integrated circuit(s) card (ICC) as an example to describe both the structure of the PP, as well as the
proposed content.
In Annex A, the guideline for preparing EFC/PP is described by using an OBE as an example of EFC
products. The communication link (between the OBE and the RSE) is based on DSRC.
Annex B gives an example of how a threat analysis can be done, while Annex C provides an overview of
the relevant security standards in the context of the EFC, which provides the background of EFC roles
and interfaces.
5.2 EFC security architecture
Figure 2 shows how this document fits in the overall picture of EFC security architecture. The shaded
boxes are the aspects mostly related to the preparation of PPs for EFC systems.
Figure 2 — Overall view of security architecture
5.3 Protection profile preparatory steps
The main purpose of a PP is to analyse the security environment of a subject and then to specify the
requirements meeting the threats that are the output of the security environment analysis. The subject
studied is called the target of evaluation (TOE). In this document, an OBE with an ICC is used as an
example of the TOE.
The preparatory work of EFC/PP consists of the steps shown in Figure 3 (in line with the contents
described in Clause 6).
6 © ISO 2017 – All rights reserved
Figure 3 — Process of preparing a Protection Profile for EFC equipment
A PP may be registered publicly by the entity preparing the PP in order to make it known and available
to other parties that may use the same PP for their own EFC systems.
5.4 Relationship between actors
By security target (ST), it means a set of security requirements and specifications to be used as the
basis for evaluation of an identified TOE. While the PP could be looked upon as the EFC toll service
providers’ requirements, the ST could be looked upon as the documentation of a supplier as for the
compliance with and fulfilment of the PP for the TOE, e.g. an OBE.
Figure 4 shows a simplified picture and example of the relationships between toll service provider,
the EFC equipment supplier and an evaluator. For an international registry organization, i.e. Common
Criteria Recognition Arrangement (CCRA) and current registered PPs, refer to Annex D.
Figure 4 — Relationships between operators, suppliers and evaluators
The ST is similar to the PP, except that it contains additional implementation-specific information
detailing how the security requirements are realized in a particular product or system. Hence, the ST
includes the following parts not found in a PP:
— a TOE summary specification that presents the TOE-specific security functions and assurance
measures;
— an optional PP claims the portion that explains PPs with which the ST is claimed to be conformant
(if any);
— a rationale containing additional evidence establishing that the TOE summary specifications
ensure satisfaction of the implementation-independent requirements and that claims about PP
conformance are satisfied;
— actual security functions of EFC products will be designed based on this ST (see example in Figure 5).
8 © ISO 2017 – All rights reserved
Figure 5 — Example of design based on a PP
6 Outlines of Protection Profile
6.1 Structure
The content of a Protection Profile for a part or interface of an EFC system is shown in Figure 6.
Figure 6 — Content of a Protection Profile
6.2 Context
Guidelines for preparing PP are as follows:
a) Overview (see A.1)
b) Target of evaluation (TOE, see A.2)
The scope of the TOE shall be specified.
c) Security environment (see A.3)
Development, operation and control methods of the TOE are described in order to clarify the
working/operation requirements. Regarding these requirements, IT assets, for which the TOE must be
protected, and the security threats to which the TOE is exposed, shall be specified.
d) Security objectives (see A.4)
Security policies for threats to the TOE are determined. The policies are divided into technical policy
and operational/control policy.
Security objectives should be consistent with the operational aim or product purpose of the TOE.
Operational/control policy is defined as personnel and physical objectives in the status for which the
TOE is used or operated. The operational/control policy includes control and operational rules for
operators.
e) Security requirements (see A.5)
In accordance with the security objectives defined in A.4, concrete security requirements for security
threats stated in A.3 are specified. The security requirements consist of functional requirements
(technical requirements) and assurance requirements for security quality.
Functional requirements are provided, selecting necessary requirements from ISO/IEC 15408-2 and
determining parameters.
Regarding assurance requirements, assurance requirements designated in ISO/IEC 15408-3 are adopted
by determining evaluation levels for assurance requirements, which are provided in ISO/IEC 15408-2
and ISO/IEC 15408-3.
f) Rationale of justification/effectiveness (see A.6)
The contents of PP are checked when necessary and cover security requirements for the TOE. The
checked items are as follows:
1) all security environments needed are covered;
2) security objectives should completely meet the security environments;
3) security requirements should implement security objectives.
10 © ISO 2017 – All rights reserved
Annex A
(informative)
Procedures for preparing documents
A.1 Overview
A.1.1 General
A general outline of the document for Protection Profile (PP) is described.
It should be noted that this clause is informative in nature. Most of the content is an example on how
to prepare the security requirements for EFC equipment, in this case, an OBE with a smart card (ICC)
loaded with crucial data needed for the electronic fee collection.
A.1.2 Identification information
Identification information for the document is as follows:
a) document title;
b) version/release number;
c) preparation date;
d) prepared by.
EXAMPLE Identification information:
1) document title: EFC On-Board Equipment Security Protection Profile;
2) reference/version number: 1.0;
3) preparation date: 2002-10-20;
4) prepared by: ABC Association.
A.1.3 Target of evaluation (TOE) description
TOE is identified as follows:
a) product;
b) version/release number;
c) developer.
EXAMPLE TOE description:
1) product: EFC On-Board Equipment;
2) version/release number: 1.0;
3) developer: ABC Co., Ltd.
A.1.4 In accordance with ISO/IEC 15408 (all parts)
The prepared “Protection Profile” in accordance with ISO/IEC 15408 (all parts) is stated explicitly.
The version and preparation data of referenced ISO/IEC 15408 (all parts) are also stated.
EXAMPLE ISO/IEC 15408 (all parts) conformance statement according to:
— ISO/IEC 15408-1 Third Edition 2009-12-15;
— ISO/IEC 15408-2 Third Edition 2008-08-19;
— ISO/IEC 15408-3 Third Edition 2008-08-19.
A.1.5 Outline of TOE
A.1.5.1 Classification of TOE
EXAMPLE
1.4.1 Classification of TOE
EFC On-Board Equipment
A.1.5.2 TOE functional outline
For users of security “Protection Profile”, the types of device described in “Protection Profile” are
described explicitly to help them determine the application.
EXAMPLE
1.4.2 TOE functional outline (OBE for EFC system)
The functional outline is as follows.
a) EFC function:
1) mutual authentication with IC card;
2) transcription (caching) of IC card data to OBE;
3) encryption of radio communication with RSE;
4) assurance of message integrity;
5) mutual authentication with RSE;
6) storage of secured information (encryption key) used in OBE during EFC transaction.
b) Set-up function:
1) authentication of set-up card;
2) caching of vehicle information from IC card to OBE.
c) HMI function:
1) report of EFC billing results to users;
2) guidance of EFC lane.
12 © ISO 2017 – All rights reserved
A.1.5.3 Evaluation Assurance Level (EAL)
Evaluation Assurance Levels for objectives are selected. Each EAL defines a package consisting of
assurance components and determines the degree of assurance requirements on security systems. The
justification for the selected EAL is stated.
EXAMPLE
A.1.5.3 EFC OBE (EAL is 5)
OBE functions as equipment for e-Commerce in EFC transactions. The security systems of EFC OBE are vulnerable
to attack under the control of individual users. Therefore, a high assurance level (EAL) will be required for EFC OBE.
A.2 Target of evaluation (TOE)
A.2.1 TOE objectives and methodology
A.2.1.1 TOE use objectives
The following indicates objectives for TOE use and the type of environment in which it is used.
EXAMPLE EFC members (users) use the EFC system at tollgates by inserting the IC card with EFC member
contract information for settlement. Vehicle information such as an automobile inspection certification is stored
in OBE beforehand. For storing vehicle information, a personalization card for initialization is used. The OBE
(TOE), which reads/writes data to IC cards for set-ups/settlements and transmits/receives data to road side
equipment for toll collection transactions, protects interface and internal data from external threats.
A.2.1.2 TOE use methodology
a) User preparations:
steps to be taken by users before use of TOE.
b) Operators preparation:
necessary hardware/software and control systems are described when operators operate TOE.
c) Operational procedures:
procedures for operation and maintenance are described.
d) Use procedures:
procedures for users are described.
e) Limitations of use:
limitations of use such as time zones and geographical zones are described.
EXAMPLE
a) User preparations:
Users request an operator to install an OBE and set up vehicle information such as automobile inspection
certification to OBE. In addition, users receive the ICC with EFC member contract information.
b) Operator preparations:
Operators issue set-up information in response to user’s requests.
c) Operation procedures:
When users are passing through tollgates, the tolls are billed to the IC cards for settlement with EFC member
contract information, which is inserted in the installed On-Board Equipment with vehicle information. When a
legitimate IC card for settlement is inserted in the OBE with correct vehicle information, the toll fee is calculated
in the communication zone of RSE at tollgates.
For a change or update of EFC member contract information, such as vehicle information, set-up cards and ICC
are updated (reissued/reregistered).
d) Use procedures:
Users use the EFC system of inserting IC cards with EFC member contract information at tollgates according to
the EFC member contract or OBE manuals.
e) Limitations of use:
In general, 24 h use is available, as long as EFC lanes are open at tollgates.
A.2.2 TOE functions
A.2.2.1 Functions provided by TOE
Functions, which are provided by the TOE, are described. All functions for data transactions, which
shall be protected, are listed.
EXAMPLE
a) EFC transactions:
1) EFC communication control function;
2) non-secure data record function;
3) HMI input/output control function;
4) IC card insert status detect function;
5) On-Board Equipment self-check function.
b) Security module:
1) data storage or protection function;
2) user access control function;
3) authentication function (DSRC, ICC);
4) encryption/decryption function;
5) ICC interface function;
6) EFC transaction interface function;
7) set-up card read function.
A.2.2.2 Functions not provided by TOE
When the TOE function is a part of the functions of an entire system, the scope of the TOE in the whole
system should be shown as in Figure A.1 which shows an example where the OBE is the scope of the TOE.
For the purpose of reference, Figure A.2 showing the overall security policy scope should be included.
14 © ISO 2017 – All rights reserved
EXAMPLE
Figure A.1 — Example where the TOE is shown in its context
Figure A.2 — Overall security policy scope
A.2.2.3 Missing functions
When functions, which usually should be provided by the TOE in this section, are not included in the
TOE, the function contents and reasoning for exclusion should be described.
A.2.3 TOE structure
A.2.3.1 Hardware structure
The structure with related hardware units on TOE operation is described. The scope of TOE in the
structure should be shown as in the example in Figure A.3. Also, the overall EFC system model of the
EFC Security Framework should be shown as in Figure A.4.
EXAMPLE
Figure A.3 — Example of TOE hardware structure
Figure A.4 — EFC system model of the EFC Security Framework
16 © ISO 2017 – All rights reserved
A.2.3.2 Software structure
The structure with related software in the operation of the TOE is described. In the structure, the scope
of the TOE in the structure should be stated. Especially, when the operation of the TOE depends on
operating system (OS) and data control programs, the distribution of functions should be described.
A.2.3.3 Rationale
It should be verified that the described items are consistent.
a) Absence of inconsistent provision items.
b) Absence of undefined or unclear sections of provided contents in this subclause.
A.3 Security environment
A.3.1 Operation/operational environment of TOE
A.3.1.1 General
Security requirements to determine security objectives for the TOE operation are provided.
A.3.1.2 Operational environments
The methodology of the use of the TOE such as the operational environment, operational time,
operational site, use procedure and location of use is described. The described contents of A.2.1.2 are
described in detail from the aspect of functionality.
a) Operational procedures
Regarding the operational procedures of the TOE, the operation of an integrated EFC system including
the related vehicles and ICC for payment are described.
b) Operational time
The operational time zone of the TOE is described.
EXAMPLE The operational time is any time that EFC vehicles use on EFC toll roads.
c) Operational sites
Operational sites of the TOE are described.
d) Use procedures
The procedures from the purchase (obtain) to the disposal of the TOE by users are described including
installation of the TOE, set-up of the TOE and operation at toll roads.
EXAMPLE 1 Users purchase EFC OBE at OBE dealers (car dealers, car shops). An OBE is installed in a vehicle.
In addition, the on-board information needed for the EFC operation such as vehicle information is stored as on-
board information.
EXAMPLE 2 After an EFC member contract is established, users get an ICC, which is issued by credit card
companies.
EXAMPLE 3 Users will be able to use the EFC system by inserting an ICC in an OBE installed in a vehicle. The
vehicles, which are capable of using EFC systems, are called EFC vehicles.
EXAMPLE 4 Users use toll roads with the ICC inserted in an OBE in an EFC vehicle and pass through the
tollgates without stopping.
Users can voluntarily dispose of unnecessary OBE.
e) Use sites
Sites, where users are able to use TOE, are described.
EXAMPLE Toll roads, along which EFC RSE are installed.
f) Limits and requirements in use such as available numbers of TOE are described.
EXAMPLE 1 The number of OBE installed per vehicle is limited to one.
EXAMPLE 2 OBE is fixed (built-in) in a vehicle.
EXAMPLE 3 OBE can be used 24 h a day as long as EFC lanes are open for operation.
A.3.1.3 Physical control
Physical control related to the operation of the TOE is described.
a) Installation sites and control
Installation sites and physical control of the TOE are described.
EXAMPLE 1 OBE is fixed (built-in) in a vehicle.
b) User unit
For use of the TOE, the physical control requirements of ICC for payments, which users possess, are
described.
EXAMPLE 2 Users are responsible for their ICC.
A.3.1.4 Personnel requirements
The personnel requirements for the responsibility and confidence of the TOE operations are described.
In addition, the requirements for potential uses, motivations, methods and expertise of attacks are
provided.
a) TOE-related agents
The following items regarding the manufacturers, operators and users of TOE are stated.
1) Type
2) Role
3) Authorization
4) Reliance
5) Risk of illicit use
6) Expertise
7) Trail
EXAMPLE 1 Personnel requirements:
Type: Manufacturer of On-Board Equipment.
Role: Manufacturing and shipping based on standard specification of EFC OBE.
Authorization: None.
Reliance: No responsibility for security control.
18 © ISO 2017 – All rights reserved
Risk of illicit use: There are risks of illicit use since the responsibility for security control is absent.
Expertise: No need of expertise for security.
Trail: Negative list check is implemented while EFC vehicles are passing through tollgates.
b) Attackers
The following items are described for illicit user requirements against which countermeasures are
taken by the TOE.
1) Type
2) Purpose of illicit use
3) Motivation
4) Means
5) Expertise
EXAMPLE 2 Attackers:
Type: Illicit third party among EFC users.
Purpose of illicit use: OBE data forgery, manipulation, obtaining of personal information. Forgery and illicit
modification of OBE medium.
Motivation: To reduce toll fees or avoid toll fee claims by illicit use of information. Sale of forged OBE.
Means: Forgery of vehicle information on On-Board Equipment. Forgery of I/F data between OBE and ICC
to counterfeit someone’s card. Forgery of EFC OBE by analysing OBE internally.
Expertise: Comprehend the internal transaction by analysing EFC On-Board Equipment internally.
A.3.1.5 Connectivity/operational environments
The environment for TOE connectivity and operation is provided. Only the structure, which is provided
in this subclause, shall be TOE.
a) Connectivity
Transactions for RSE at tollgates and ICC needed for the operation of the TOE are described.
EXAMPLE
— OBE exchange information via radio communication (5,8 GHz) with RSE at tollgates.
— OBE read IC card data (card number, ETC member contract information) before vehicles pass through
tollgates. When vehicles pass through tollgates, OBE send applicable IC card internal data to RSE to transmit
billing and transaction record data.
b) Operational requirements
Hardware/software requirements (CPU implementation speed, required memory, input/output
devices) needed for operation of the TOE are described.
A.3.1.6 Rationale
It is verified that the described items are consistent.
a) Absence of inconsistent provision items.
b) Absence of undefined or unclear sections of provided contents in this subclause.
A.3.2 Security threats
A.3.2.1 Determination of target resources for protection
a) Selection of target resources for protection
Target resources for protection, to be protected by the TOE, are determined. Resources, which negatively
impact services of the TOE by falsification, alteration and loss, are targeted for protection. Regarding
determined individual targeted resources for protection, the lifecycle such as generation, transaction,
storage and disposal are clearly described. If there are indirect resources for a TOE transaction, the
indirect resources are determined as well.
EXAMPLE 1
1) Target protection resources to be protected by the TOE:
— ETC member contract information: ICC internal data (i.e. IC card number);
— vehicle information: OBE internal data such as vehicle classification codes;
— tollgate information: exit/enter information, barrier information and transaction record information;
— information stated above, transmitted by radio communication through OBE between road side units at
tollgates and ICC;
— toll information: storage in ICC such as billing information.
2) Target resources for protection such as lifecycle:
— OBE installation in a vehicle;
— transcription of vehicle information into OBE;
— OBE operation at toll roads;
— OBE disposal.
b) Evaluation of target resources for protection
The values of determined target resources for protection are evaluated. The evaluation is divided into
three levels as follows:
Level 1: security problems’ impact on the entire system for the TOE, e.g. the system might be
malfunctioning or down.
Level 2: security problems drastically compromise the value of the system for the TOE, e.g. the
social responsibility for the systems is impaired; however, restoration of systems is attainable.
Level 3: security problems hinder the operation of the TOE, e.g. operation of the system is
temporarily interrupted, resulting in serious impact on the users.
EXAMPLE 2
Evaluation of target resources for protection:
Level 1: None (no target resource for protection, which impacts systems such as destroying ETC systems);
Level 2: ETC member contract information;
Level 3: Vehicle information, tollgate information, toll information.
A.3.2.2 Identification of security threats
Potential threats are identified by level of determined target resources for protection. Concrete
analysis of target resources for protection is implemented in terms of who (what), where, when,
20 © ISO 2017 – All rights reserved
how (counterfeiting, tapping, destruction), means (available resources, interface, expertise), threats
(falsification, exposure, service interruption) and reasons.
a) Who (what):
who (what) generates threats is stated.
b) Target resource:
target resource for threats (billing data, personal information) is stated.
c) Contents of threats:
major threats are as follows:
1) lack of confidentiality;
2) lack of protection;
3) lack of availability;
4) lack of responsibility;
5) lack of integrity;
6) lack of reliability.
d) Means:
means generating attacks are stated.
e) Methodology:
methodology of attacks is stated.
f) Motivation:
motivation of attacks is stated.
g) Opportunity:
opportunity of attacks is stated.
h) Weak points:
security weaknesses are stated.
Threat analysis for lifecycle of target data for protection is shown in Table A.1.
Table A.1 — Threat analysis for lifecycle of ETC On-Board Equipment data for protection —
Example
Lifecycle: Threat analysis for “3. OBE operation at toll roads”
Threat
Information
for
Methodology,
Who Where When Threats Why
protection
means
ETC member Forge ICC or I/F Forgery and
While inserting Avoid toll
contract OBE data to falsify altering of ICC
ICC fee claim
information someone’s card internal data
Forgery and
Vehicle Anytime/while Forgery of vehicle Reduce toll
OBE manipulation of
information passing tollgates codes of OBE fee
OBE internal data
Illicit
Tollgate Tapping of radio
third
Eavesdropping
information communication
party
Obtain
of radio
data
personal
communication
Tollgate Communication
information
Communication
lanes (billing)
Toll fee
Replay the
data manipula-
Reduce or
information
eavesdropped
tion
avoid toll fee
data
Replay attack
A.3.2.3 Rationale
It is verified that the described items are consistent.
a) Absence of inconsistent provision items.
b) Absence of undefined or unclear sections of provided contents in this subclause.
A.3.3 Security policy of operational entity
A.3.3.1 General
Security items for operational entities for the TOE are provided in accordance with the rules and
policies. The document names describing concrete rules are described.
A.3.3.2 Identification of security policies of operational entities
a) Use policy of target resource for protection
Use policy (to whom, what capability, when, where) of target resource for protection is provided.
b) Maintenance policy (update, disposal) of target resource for protection
c) Operational rules and applicable laws for security
i.e. security policy based on “Law for prohibiting illicit access” is provided.
d) System and responsibility/duty for security policy
The security control/promotion system, responsibility and role are provided.
22 © ISO 2017 – All rights reserved
A.3.3.3 Rationale
Among security policy items of each operational entity, it is checked that there is no contradiction in
the provision contents with the methodology and results being described.
a) Absence of inconsistent provision items.
b) Absence of undefined or unclear sections of provided contents in this subclause.
A.4 Security objectives
A.4.1 General
Regarding security threats listed in A.3.2, security objectives are determined from both aspects of
technical objectives, which are provided by EFC systems or the operational environment of the EFC
system, and operation control objectives.
A.4.2 Technical security objectives
Technical security objectives provide security objectives, which are implemented by security functions
such as encryption of data and control of access authentication.
a) For determination of security objectives, technical security objectives against threats are clearly
described.
b) Security objectives are determined from the aspect of “control”, “prevention”, “detection” and
“recovery”.
Control: the generation of security threats is controlled.
EXAMPLE 1 Billing resource information such as EFC contract information is stored so securely in ICC and
SAM installed in OBE for caching that it is protected from tampering.
Prevention: prevent security destruction when security threat is generated.
EXAMPLE 2 Data are protected by encrypted data of radio communication information.
Detection: security threats are detected.
EXAMPLE 3 Data falsification is detected by adding an authentication code to the message data.
Recovery: when security threats are detected, the original secure status will be restored.
EXAMPLE 4 When a forgery of OBE or ICC is detected, negative information is recorded and the use is
terminated. For legitimate users, a new OBE or ICC is reissued.
The following are some of the basic elements of security objectives.
a) Availability
Information transaction resource is effectively used anytime anywhere, when needed. Major
security objectives are as follows.
1) Term of validity: setting the term of validity for IC cards, IC cards need to be changed
periodically.
2) Damage control: equipment at tollgates controlling toll billing information should have dual
configuration to avoid being damaged.
--------------------
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.