1. Trang chủ
  2. » Kỹ Thuật - Công Nghệ

Tiêu chuẩn iso ts 17574 2017

60 1 0

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 60
Dung lượng 2,48 MB

Nội dung

TECHNICAL SPECIFICATION ISO/TS 17574 Third edition 2017-03 Electronic fee collection — Guidelines for security protection pro files Perception de télépéage — Lignes directrices concernant les profils de protection de la sécurité Reference number ISO/TS 17574:2017(E) © ISO 2017 ISO/TS 17574:2017(E) COPYRIGHT PROTECTED DOCUMENT © ISO 2017, Published in Switzerland All rights reserved Unless otherwise specified, no part o f 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 o f the requester ISO copyright o ffice Ch de Blandonnet • 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 ISO/TS 17574:2017(E) Contents Page Foreword iv Introduction v Scope Normative references Abbreviated terms EFC security architecture and protection pro file processes 5.1 General 5.4 Relationship between actors Outlines of Protection Pro file 6.1 Structure 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 Terms and de finitions E FC s ecurity architecture Pro tectio n p ro file p rep arato ry s tep s © ISO 2017 – All rights reserved iii ISO/TS 17574:2017(E) Foreword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies) The work o f 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 o f electrotechnical standardization The procedures used to develop this document and those intended for its further maintenance are described in the ISO/IEC Directives, Part In particular the different approval criteria needed for the di fferent types o f ISO documents should be noted This document was dra fted in accordance with the editorial rules of the ISO/IEC Directives, Part (see www.iso org/directives) Attention is drawn to the possibility that some o f the elements o f this document may be the subject o f patent rights ISO shall not be held responsible for identi fying any or all such patent rights Details o f any patent rights identified during the development o f 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 in formation given for the convenience o f users and does not constitute an endorsement For an explanation on the meaning o f ISO specific terms and expressions related to formity 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.iso.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 has been redrafted and shortened; — Clause has been updated with harmonized terms; — requirements updated as to reflect the latest version o f the ISO/IEC 15408 series; — a new Clause has been added, comprising much of the text from the Scope of the previous edition iv © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) Introduction Electronic fee collection (EFC) systems are subject to several ways o f fraud both by users and operators but also from people outside the system These security threats have to be met by di fferent types o f 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 o f 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 re fers to a Japanese national EFC system and should only be regarded as an example A fter 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 re fer 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 o f requirements for the security functions and assurance o f IT-relevant products and systems Operators, organizations or authorities defining their own EFC/PP can use these requirements This will be similar to the di fferent 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 o f the government or designated private evaluation agencies © ISO 2017 – All rights reserved v TECHNICAL SPECIFICATION ISO/TS 17574:2017(E) Electronic fee collection — Guidelines for security protection pro files Scope This document provides guidelines for preparation and evaluation o f security requirements specifications, re ferred 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 o f security requirements for a category o f 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 i f a Protection Profile already exists for the subsystem in consideration The target o f evaluation (TOE) for EFC is limited to EFC specific roles and inter faces as shown in Figure Since the existing financial security standards and criteria are applicable to other external roles and inter faces, they are assumed to be outside the scope o f TOE for EFC Figure — Scope of TOE for EFC The security evaluation is per formed by assessing the security-related properties o f roles, entities and inter faces defined in security targets (STs), as opposed to assessing complete processes which o ften are distributed over more entities and inter faces than those covered by the TOE o f this document NOTE Assessing security issues for complete processes is a complimentary approach, which may well be beneficial to apply when evaluating the security o f a system Normative references There are no normative references in this document © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) Terms and de finitions For the pu rp o s e s o f th i s c ument, the fol lowi ng term s and defi nition s 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 s e c u rity re qui rements to a s s ure fidence i n the i mplementation o f fu nc tiona l re qu i rements 3.2 audit i ndep endent review and exam i nation in order to en s u re compl i ance operational procedures and to recommend associated changes with e s tabl i s he d p ol ic y and 3.3 availability prop er ty o f b ei ng acce s s ible a nd u s able up on demand b y a n authori z e d entity [SOURCE: ISO/TS 19299:2015, 3.6] 3.4 certi fication pro ce dure b y wh ich a p ar ty give s written a s s urance th at a pro duc t, pro ce s s , or s er vice form s to s p e c i fie d re qu i rements [SOURCE: ISO/TS 14907-1:2015, 3.3] 3.5 fidentiality 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 s e t o f as s u nce re qu i rements , u s ua l ly i nvolvi ng c umentation, ana lys i s and te s ti ng , repre s enti ng a p oi nt on a pre defi ne d as s u nce s c a le, that form an as s u nce p ackage 3.8 functional requirement re qu i rement for a fu nc tion that a s ys tem or s ys tem comp onent i s able to p er form 3.9 integrity prop er ty that d ata have no t b e en a ltere d or de s troye d i n an unauthori z e d man ner 3.10 international registrar organ i z ation authori z e d to re gi s ter pro te c tion pro fi le s at an i nternationa l level © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) 3.11 key management generation, d i s tribution, s torage, appl ic ation and revo c ation o f enc r yp tion keys 3.12 On-Board Equipment OBE required equipment on-board a vehicle for performing required EFC functions and communication services N o te to entr y: T he O B E e s no t ne e d to i nclude p ayment me a n s 3.13 personalization card set-up card IC card to transcribe individual data such as vehicle information into On-Board Equipment 3.14 rationale veri fication pro ce s s de term i n i ng th at a pro duc t o f e ach ph as e o f the s ys tem l i fe c ycle development pro ce s s fu l fi l s all the re qu i rements s p e c i fie d i n the previou s ph as e 3.15 reliability abi l ity o f a device or a s ys tem to p er form its i ntende d fu nc tion u nder gi ven cond ition s o f u s e for a s p e ci fie d p erio d o f ti me or nu mb er o f c ycle s [SOURCE: ISO/TS 14907-1:2015, 3.17] 3.16 road side equipment RSE e quipment lo c ate d a long the ro ad , either fi xe d or mobi le 3.17 secure application module SAM phys ic a l mo du le th at s e c u rely e xe c ute s cr yp to graph ic fu nc tion s and s tore s keys [SOURCE: ISO/TS 19299:2015, 3.35] 3.18 security policy s e t o f r u le s that re gu l ate how to h and le s e c u rity th re ats or defi ne the appropri ate s e c urity level [SOURCE: ISO/TS 19299:2015, 3.36] 3.19 security target ST s et o f s ecurity re qui rements and s p eci fications to b e us e d as the b as is for evaluation o f an identi fie d TOE 3.20 security threat p o tenti a l ac tion or man ner to violate the s e c urity o f a s ys tem 3.21 target of evaluation TOE s e t o f s o ftwa re, fi rmwa re and/or h ardwa re p o s s ibly accomp a nie d b y gu ida nce [SOURCE: ISO/IEC 15408-1:2009, 3.1.70] © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) 3.22 threat agent entity th at s the i ntention to ac t advers ely on a n a s s e t [SOURCE: ISO/TS 19299:2015, 3.40] 3.23 toll charger entity wh ich levie s tol l for the u s e o f veh icle s i n a tol l doma i n N o te to entr y: I n o ther c u ments , the ter m s op erato r o r tol l o p erator c a n b e u s e d [S O U RC E : I S O 175 : 010 , 16 , mo d i fie d] 3.24 toll service provider TSP entity provid i ng tol l s er vice s i n one or more tol l domai n s N o te to entr y: I n o ther c u ments , the ter m s i s s uer o r contrac t i s s uer m ight b e u s e d N o te to entr y: T he to l l s er vice p rovider c a n p rovide the O B E or m ight p rovide on l y a m agne tic c a rd o r a s m a r t c a rd to b e u s e d with a n O B E p rovide d b y a th i rd p a r ty ( l i ke a mo bi le telep ho ne a nd a S I M c a rd c a n b e ob ta i ne d from different parties) N o te to entr y: T he to l l s er vice pro vider i s re s p on s ib le for the op eratio n (fu nc tion i ng) o f the O B E [S O U RC E : I S O 175 : 010 , , mo d i fie d] Abbreviated terms CC CCRA CN DSRC EAL EFC GNSS HMI I/F ICC IT OBE PP RSE SAM Common Criteria Common Criteria Recognition Arrangement cellular networks dedicated short-range communication Evaluation Assurance Level electronic fee collection glob a l navigation s atel l ite s ys tem s human machine interface interface integrated circuit(s) card i n formation te ch nolo g y On-Board Equipment P ro te c tion P ro fi le road side equipment secure application module © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) NOTE It is easier to veri fy security functional requirements with a matrix describing the relationship between technical security objectives and security functional requirements An example o f such a matrix is given in Table A.6 40 © ISO 2017 – All rights reserved © ISO 2017 – All rights reserved Table A.6 — Rationale of security functional requirements (needs) Functional requirements FIA_UAU.3 (User authentication) Information unit control (anti-tampering) — Security objectives Data User control Expiration Data (negative control protection record)list Remarks Identification/ authentication Access control confidentiality ○ — — — — — — — ○ — ○ — ○ — — FDP_ACC.1 (Access control policy) FDP_ACF.1 — — ○ — — — — — — — ○ — — — — — — — — ○ — — — — — — — ○ (Security data) — — — — — — — — — ○ — — FPT_ITI.1 (Integrity o f TSF data) — — — — — ○ — — FPT_PHP.1 (TSF physical protection) ○ — ○ (Security — — (Inter-TSF trusted channels) (Access control functions) FDP_UCT.1 (Inter-TSF user data confidentiality trans fer protection) FPT_ITC.1 (Confidentiality o f TSF data) FDP_UIT.1 (Inter-TSF user data integrity transfer protection) ○ applicable (○) potentially applicable — not applicable — — — data) 41 ISO/TS 17574:2017(E) FTP_ITC.1 Information unit control (anti-tampering) — Security objectives authentication Access control confidentiality — — — ○ — — — — — ○ — ○ — ○ — FTA_NLC.1 — — — — — — (○) — FTA_VTC.1 — — — — (○) — — — FDP_DAU.1 — — — — — ○ — — FMT_SAE.1 (Security attribute expiration) FTA_TSE.1 (TOE session establishment) (New requirement) (New requirement) (Data authentication) ○ applicable (○) potentially applicable — not applicable Data User control Expiration Data (negative control protection record)list Remarks Identification/ Functional requirements ISO/TS 17574:2017(E) 42 Table A.6 (continued) © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) A.6.3 Sufficiency The rationale for each security objective to be su fficiently prescribed by the provided functional requirements is explained In particular, an explanation is given as to how functional requirements are operated for security objectives or how dependency between relevant functional requirements fits in with security objectives EXAMPLE Security functional requirements (su fficiency): Security objectives: su fficiency o f selected functional requirements for authentication Su fficiency: — rationale o f authentication is executed by checking exchanged data; — rationale o f authentication is prescribed by FIA_UAU.3 (functional requirements) Data are certified using authenticators, which are generated from cryptographic keys and algorithms shared in the OBE and the RSE A.6.3.4 Complement It is verified that security functional requirements complement each other and that no contradiction is generated due to the complement (see Table A.7): — there are functional requirements to bypass for the operation o f relevant functional requirements by other functional requirements; — there are functional requirements to control the interference of relevant functional requirements by other functional requirements; — there are functional requirements to control the illicit operation of relevant functional requirements by other functional requirements; — there are functional requirements to veri fy that relevant functional requirements are not operated in the wrong status by other functional requirements Table A.7 — Example of A.2 — Rationale of security functional requirements (complement) Functional requirements FIA_UAU.3 Requirements to provide security defence Blocking o f bypasses FDP_ACF.1 Security functional requirements (complement) Non-interference FPT_PHP.1 Non-operation controls N/A Complement Blocking o f bypasses: FDP_ACF.1 Security requirements to protect data using access control functions Bypasses are blocked by installing access control functions in the module that is tamper-proof Non-inter ference: FPT_PHP.1 Security requirements to protect data from illicit inter ference using physical security functions Illicit inter ference is prevented by installing security functions in the module that is tamper-proo f Non-operation controls: N/A = not applicable A.6.3.5 Availability It is verified that each security functional requirement is realized under the TOE operational requirements Availability is verified from the aspect o f use, management and operation EXAMPLE Security functional requirements (availability): © ISO 2017 – All rights reserved 43 ISO/TS 17574:2017(E) Possibility o f realization Functional requirements: FIA_UAU.3 OBE data are enciphered by a third party and stored in the module that is tamper-proo f In the case o f ETC use, data authentication between ICC and RSE with cryptographic keys provided by the same third party is implemented Use o f the ETC system is rejected when the authentication between the ICC and the RSE is not valid A.6.3.6 Mutual consistency of security functional requirements It is verified that security functional requirements are consistent with each other The relationship between functional requirements is dependence, refinement or augmentation, which indicates the absence of contradiction with the provided contents A.6.3.7 Dependency of security functional requirements When there is dependency at the component level, it is verified that all the related components are selected A.6.4 Rationale of strength of functions In the case o f requiring security functional strength (including AVA_SOF.1), the validity is explained from the aspect of motivation of threats, resources and countermeasure techniques A.6.5 Rationale for security assurance requirements — Validity o f assurance levels It is verified that target assurance levels are not too low for identified threats Concrete evaluation for the validity o f target assurance levels is conducted based on: 1) level of attack potentials on the TOE; 2) assurance degree for the TOE operation/operational environment; 3) TOE users (specified or unspecified); 4) impact degree on peripheral environment when TOE security has been destroyed; 5) impact on development cost; 6) competition with other companies — Realization of assurance levels It is verified that target assurance levels can be realized from technical and financial aspects A.6.6 Rationale of control/operational requirements The validity for control/operational requirements is explained A.6.7 Rationale of assurance methodology Assurance requirements corresponding to each assurance methodology are clearly shown It is explained that assurance means meeting assurance requirements In addition, it is explained that the content is appropriate for the operation It is verified that sentences that are required by each assurance requirement exist and the contents o f them are su fficient 44 © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) Annex B (informative) Example of threat analysis evaluation method B.1 Identi fication of threats B.1.1 General Threats can be divided into the following three general categories (see Table B.2): a) intentional threats (attacks); b) administrative threats; c) accidental threats B.1.2 Intentional threats (attacks) Intentional threats are those that are made by malicious intruders (third parties) They can be classified into the following three categories: a) fraudulent use of equipment; b) alteration of accumulated data; c) interception and abuse of personal data B.1.3 Administrative threats Administrative threats are those that are caused by a lack o f security in administration and management, the abuse o f privileges and EFC These threats can be classified into the following three categories: a) intrusion into the subscriber/user database; b) tapping of personal data in the network; c) raudulent access into system databases or network control functions f B.1.4 Accidental threats Accidental threats are those that are caused by operational errors by the user and communication transmission errors B.2 Estimation of risks a) Likelihood of occurrence — those individuals lacking expertise — those individuals with expertise — those groups possessing expertise — those groups possessing expertise with sizable investment © ISO 2017 – All rights reserved 45 ISO/TS 17574:2017(E) — those company level parties with expertise — immense damage via system destruction (unrestorable) — immense damage via limited system destruction (restorable) — specified/unspecified users economically a fflicted b) Impact value as a result of double or triple charging (loss of credit) — leakage of charging data with continuation and expansion — leakage of charging data without continuation (involved parties are a fflicted) (involved parties are a fflicted) c) Exposure factor The exposure factor is calculated by multiplying a) by b) B.3 Evaluation and determination of countermeasures B.3.1 Evaluation method The threats are evaluated by the above threat classification (A > B > C) and risk value (see Table B.1) Table B.1 — Evaluation method Classi fication A B Likelihood of occurrence Impact value Exposure factor B.3.2 Determination of security countermeasures A threshold value is established for each threat identification in order to determine whether or not to carry out any security countermeasures I f the risk value equals or exceeds the threshold value, then security countermeasures should be carried out Examples o f the values are given as follows EXAMPLE — threshold value A ≥ 5; — threshold value B ≥ 10; — threshold value C ≥ 15 46 © ISO 2017 – All rights reserved © ISO 2017 – All rights reserved Table B.2 — Threat analysis result for users (OBE and ICC interfaces) — Example Objects of at- Outlines tacks Who When Forgery OBE and falsi- Dishonfication est third of OBE party modules Anytime Where What Why Reducing OBE tolls, sale of forged OBE OBE and falsi- Dishon- Anytime, fication est third while of OBE party passing internal EFC lanes data Theft and Dishonloss of est third OBE party Anytime Forgery ICC imate OBE and Authentication, forging the mod- anti-tamperules, implementing ing, access false communica- restriction tion transaction with RSE cation LikeliExpohood of Impact sure occur- value factor rence Toll road operators OBE manufacturers A 2 Anytime OBE Reducing tolls Where OBE is Self-use, inOBE sale to third stalled party and kept Making unlimited use of cards ICC prepaid for self-use or sale to third party function, mesauthenForging vehicle sage tication, road model data in OBE side judgement to reduce tolls check, check expiration date of data Enhancement o f fixed method for vehicles, Theft management using theft reports Analysing microchips inside Authentication, legitimate prepaid tampering, accards to forge them for unlimit- cess restriction ed use Toll road operators A OBE manufacturers Users A/C 5 Toll road manufacturers Card issuers A 47 ISO/TS 17574:2017(E) and falsi- Dishonfication est third of ICC party modules Analysing legit- Victims Classi fi - Encryption Forgery OBE How Functions for security improvement Objects of at- Outlines tacks Forgery Who When ICC, and falsi- Dishon- Anytime, OBE/ ICC in- fication third while of OBE est inserting terface internal party ICC data Where What Why How Forging the microchip of ICC Toll charges and the data on avoided (bill- interface as well system) as masquerading ICC ing and unlimited as another user use (prepaid (billing system) system) or increasing the usage value (prepaid system) Functions for security improvement Victims Authentication, encryption function, road judgement check, access restriction Toll road operators Card issuers Classi fi - cation A LikeliExpohood of Impact sure occur- value factor rence ISO/TS 17574:2017(E) 48 Table B.2 (continued) © ISO 2017 – All rights reserved © ISO 2017 – All rights reserved Table B.2 (continued) Objects of at- Outlines tacks ICC Who DishonTheft and est user loss of ICC Honest user Acqui- DishonOBE of and ICC sition third personal est party data transOBE/ ICC action ICC in- interferterface ence Dishonest users Honest users When Anytime Anytime While passing tollgates, while accessing ICC Where What Why Theft Victims Users Management Toll road using theft re- operators ports, individu- (no debts) al vigilance Card issuers Forging RSE and Authentication, reading the data encryption from OBE and ICC function, ac- Users at will cess restriction Classi fi - cation LikeliExpohood of Impact sure occur- value factor rence A 15 A A 10 Physically and electrically inter- fering with OBEICC communica- ICC transaction tion on interface verification, Toll road (running through OBE and ICC operators ICC, intentional software lock aulty contact) or accidental faulty f contact 49 ISO/TS 17574:2017(E) Where ICC is distrib- ICC Toll charges uted avoided and stored Where OBE and ICC are in- OBE, Illicit use of stalled, distrib- ICC personal data uted and stored Abusing data without updating the ICC, Lanes OBE- interfering sys at toll- ICC with tem to allow gates inter- unlimited (in-ve- face card usage hicle) (intentional), and careless errors (unintentional) How Functions for security improvement ISO/TS 17574:2017(E) Annex C (informative) Relevant security standards in the context of the EFC Figure C.1 ISO/TS 19299 s howi ng releva nt s e c u rity s ta nda rd s in the conte xt of the E FC is ab s trac te d from Figure C.1 — Relevant security standards in the context of the EFC — Security framework 50 © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) Annex D (informative) Common Criteria Recognition Arrangement (CCRA) D.1 Overview In October 1998, a fter years o f intense negotiations, government organizations from the United States, Canada, France, Germany and the United Kingdom signed a historic mutual recognition arrangement for common criteria-based evaluations The Arrangement, o fficially known as the “Arrangement on the Recognition o f Common Criteria Certificates in the Field o f IT Security”, was a significant step forward for government and industry in the area o f IT product and protection profile security evaluations The partners in the Arrangement share the following objectives in the area o f common criteria-based evaluations o f IT products and protection profiles: — to ensure that evaluations o f IT products and protection profiles are per formed; — high and consistent standards are seen to contribute significantly to confidence in the security o f those products and profiles; — to increase the availability o f evaluated, security-enhanced IT products and protection profiles for national use; — to eliminate duplicate evaluations o f IT products and protection profiles; — to continuously improve the e fficiency and cost-e ffectiveness o f security evaluations and the certification/validation process for IT products and protection profiles The purpose o f this Arrangement is to advance those objectives by bringing about a situation in which IT products and protection profiles which earn a common criteria certificate can be procured or used without the need for them to be evaluated and certified/validated again It seeks to provide grounds for confidence in the reliability o f the judgments on which the original certificate was based by declaring that the certification/validation body associated with a participant to the Arrangement shall meet high and consistent standards The Arrangement specifies the conditions by which each participant will accept or recognize results o f IT security evaluations and the associated certifications/validations conducted by other participants and to provide for other related cooperative activities A management committee, composed o f senior representatives from each signatory’s country, has been established to implement the Arrangement and to provide guidance to the respective national schemes conducting evaluation and validation activities The current signatories to the Arrangement are shown in D.2 and current registered PPs are shown in D.3 A complete copy o f the Common Criteria Recognition Arrangement can be obtained by following the download instructions: https://www.commoncriteriaportal org/ccra/ D.2 CCRA participants The CCRA participants can be obtained by following the download instructions: commoncriteriaportal org/ccra/members/ http://www D.3 Registered Protection Pro files The registered Protection Profiles can be obtained by following the download instructions: www.commoncriteriaportal org/pps/ © ISO 2017 – All rights reserved http:// 51 ISO/TS 17574:2017(E) Bibliography [1] ISO 14906:2011/Amd1: 2015, Electronic fee collection — Application interface definition for dedicated short-range communication [2] ISO 16609, [3] [4] ISO 17573:2010, Electronic fee collection — Systems architecture for vehicle-related tolling ISO 17575-1, Electronic fee collection — Application interface definition for autonomous systems — [5] [6] techniques Financial services — Requirements for message authentication using symmetric Part 1: Charging ISO 17575-2, Electronic fee collection — Application interface definition for autonomous systems — Part 2: Communication and connection to the lower layers ISO 17575-3, Electronic fee collection — Application interface definition for autonomous systems — Part 3: Context data [7] ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes [8] ISO/IEC 9798-4, Information technology — Security techniques — Entity authentication — Part 4: (MACs) — Part 1: Mechanisms using a block cipher Mechanisms using a cryptographic check function [9] ISO/IEC 10118 (all parts), Information technology — Security techniques — Hash-functions [10] ISO/IEC 15408-1:2009, Information technology — Security techniques — Evaluation criteria for IT security — Part 1: Introduction and general model [11] ISO/IEC 15408-2, Information technology — Security techniques — Evaluation criteria for IT security — Part 2: Security functional components [12] ISO/IEC 15408-3:2008, Information technology — Security techniques — Evaluation criteria for IT security — Part 3: Security assurance components [13] ISO/IEC TR 15446, Information technology — Security techniques — Guide for the production of Protection Profiles and Security Targets [14] ISO/TS 19299:2015, Electronic fee collection — Security framework [15] CEN/TS 16702-1, Electronic fee collection — Secure monitoring for autonomous toll systems — Part 1: Compliance checking [16] CEN/TS 16702-2, Electronic fee collection — Secure monitoring for autonomous toll systems — Part 2: Trusted recorder 52 © ISO 2017 – All rights reserved ISO/TS 17574:2017(E) ICS  03.220.20; 35.240.60 Price based on 52 pages © ISO 2017 – All rights reserved

Ngày đăng: 12/04/2023, 18:19