国家标准 GB/T31502一2015 信息安全技术电子支付系统安全保护框架 Informationseeuritytechnology一 Seeurityprotectframeworkofeleetromicpaymenmtsystem 2015-05-15发布 2016-01-01实施国家质量监督检验检疫总局发布国家标准化管理委员会国家标准
GB/I31502一2015 目次前言引言范围规范性引用文件术语和定义符号与缩略语 4.1符号表示 4.2缩略语电子支付系统描述电子支付系统模型 5.1 5.2电子支付系统工作模式 5.3受保护资产安全问题定义 6.1 概述 6.2威胁 6.3组织安全策略(SOP 6.4假设(SAS) 6.5安全问题定义理由安全目的 --* 7.1 概述 8 72针对评估对象[ToE]的安全目的(oET 7.3针对评估对象[TOE]运行环境的安全目的(0TE 安全功能要求 8.1 19 概述 8.2安全审计(FAU类 32 8.3通信(FCO类 35 8.4密码支持(FCS类 35 8.5用户数据保护(FDP类 8.6标识和鉴别(FIA类 40 8.7 安全管理(FMT类 4 8.8TsF保护(FPT类安全保证要求 l0 国家相关标准的部分依从性分析 11组织安全策略示例附录A资料性附录电子支付系统的行为模型
GB/I31502一2015 附录B规范性附录安全问题定义理由 69 74 附录C规范性附录安全目的理由 78 附录D(规范性附录安全保证要求 80 附录E(规范性附录对国家相关标准的部分依从性分析附录F(资料性附录组织安全策略示例可疑交易预警规则参考文献 +
GB/T31502一2015 前言本标准按照GB/T1.1一2009给出的规则起草请注意本文件的某些内容可能涉及专利本文件的发布机构不承担识别这些专利的责任本标准由全国信息安全标准化技术委员会(SAC/TC260)提出并归口本标准起草单位:北京多思科技工业园股份有限公司、农业银行、金融电子化公司、国家信息安全工程技术研究中心,东方集团网络信息安全技术有限公司、北京大秦兴宇电子有限公司、北京天宏绎网络技术有限公司、北京科蓝软件系统有限公司、长城瑞通(北京)科技有限公司,重庆银行,南充市商业银行本标准主要起草人刘大力、李宽、沈敏锋、韩琳琳,吴义章、吴锋、刘运、文伸慧、沈听立.,康伟,张磊于敬新、崔新杰、罗勇、夏鹏轩,闫风如、陈辉武、,王庆元、左小波、邱岩、张春阳、黄光伟、邢呈礼、高艳芳王州府 m
GB/I31502一2015 引言本标准以国际通行的信息技术安全性评估准则为基础,结合我国现阶段电子支付系统的特点,按照我国有关法律、法规和政令的要求,以自主可控为原则,为公共类电子支付系统的信息安全提供一个公共框架;是进一步完善相关国家标准及行业标准的重要步骤;为构建、运行公共电子支付系统,提供支撑
GB/I31502一2015 信息安全技术电子支付系统安全保护框架范围本标准在给出电子支付系统模型的基础上,为公共类电子支付系统的信息安全提供了一个公共框架,主要包括安全问题定义、安全目的、安全功能需求和安全保障需求本标准适用于安全构建、运行公共类电子支付系统规范性引用文件下列文件对于本文件的应用是必不可少的凡是注日期的引用文件,仅注日期的版本适用于本文件凡是不注日期的引用文件,其最新版本(包括所有的修改单)适用于本文件信息技术安全技术信息技术安全性评估谁则第1部分简介和一般模型 GB/T18336.1 GBy/T18336.2信息技术安全技术信息技术安全性评估准则第2部分安全功能组件信息技术安全性评估准则第3部分安全保障组件 GB/T18336.3信息技术安全技术术语和定义 GB:/T18336.1界定的以及下列术语和定义适用于本文件 3.1 电子支付eleetroniepayment 采用数字化方式,在电子终端、信息传输通道以及相关系统的支持下,进行支付的行为 3.,2 支付通道transaetionchamnel 在电子支付交易过程中,电子支付凭据与支付终端以及支付终端与支付安全前置之间实现信息传输的途径 3.3 公共网络通道publicnetworkchannel 支持电子支付交易的公共网络基础设施在电子支付领域通常简称为网络 3.4 接触通道eontaetchamnel 支持电子支付交易的实体直接连接方式 3.5 电子支付凭据eleetronicpaymentcredential 在电子支付过程中,用以最终确定支付相关账户的凭据电子支付凭据可能是有载体的,也可能是无载体的,同一电子支付凭据可能记载在不同的载体中 3.6 电子支付凭据载体eleetronicpaymentcredentialscarrier 记载电子支付凭据的介质不同的电子支付凭据载体,其安全性是不同的
GB/I31502一2015 电子支付凭据持有者eleetronicpaymenteredentialholder 合法拥有电子支付凭据的人对电子支付凭据记录了持有者信息的,电子支付凭据持有者的信息与电子支付凭据内部记录的信息应一致 3.8' 受理方accepter 向电子支付凭据持有者提供通道,并在需要时协助电子支付凭据持有者完成电子支付交易的机构 3.9 受理方操作员operaturofacepter 协助电子支付凭据持有者完成电子支付交易的人员,向受理方负责 3.10 中介方intermediaury 在电子支付交易中,按照付款方或收款方提出的电子支付交易请求,代为完成资金转移者 3.11 安全域seeuritydomain 在电子支付交易的过程中,遵守相同的安全策略的用户和系统的集合 3.12 可信信道trustedchamnel 为了支持安全功能策略，电子支付系统安全功能同远程可信IT产品进行所需信任通信的一种手段 3.13 可信路径trustedpath 为了支持安全功能策略,用户能同电子支付系统安全功能进行所需信任通信的一种手段 3.14 电子支付系统安全保护seeurityproteetofeleetronicpaymentsystem 对电子支付系统信息的保护及其相关的保护措施,保护电子支付信息在采集,传输和处理中免遭未授权访问保密性、修改(完整性)和对授权用户的可用性,以及支持安全管理的可核查性和抗抵赖性等在具备条件的情况下,对具有本标准所述电子支付系统特征的信息系统编制保护轮廓(Proteeionm Profile,以下简称;PP)和安全目标(SecurityTarget,以下简称;ST),将有助于有效评价该电子支付系统的安全水平,发现潜在的风险,评估可能导致的损失,以便给出适宜的风险应对措施符号与缩略语 4.1符号表示本标准对受保护资产,安全问题、安全目的和安全需求均按可引用的单元进行了编码,以便于进行引用和参照编码采用了与安全功能要求和安全保证要求协调的方式,编码的首字母如表1所示
GB/T31502一2015 表1类编码对象编码对象编码首字母受保护资产安全问题安全目的安全功能要求安全保障要求 4.2 缩略语下列缩略语适用于本文件 EPS;电子支付系统(ElectronicPaymentSystem IT;信息系统(InformationTechnoogy) PIN;个人鉴别码(PersonalldentificationNumber PP保护轮廓(ProteetionProfile' ST;安全目标(SecurityTarget) S" ofEvaluation TOE:评估对象(Target TSF:TO)E安全功能(TOESecurityFunctions) TsP;ToE安全策略(ToEsecurityPolicy) 电子支付系统描述 5.1电子支付系统模型 5.1.1概述本章给出了电子支付概念和电子支付系统模型,其中电子支付概念仅描述了一种典型状况,其目的在于使本标准阅读者能较快和准确地理解模型,并将视角聚焦于电子支付系统中的安全保护问题 5.1.2电子支付概念在电子支付中付款方与受理方交互,抛出付款申请;受理方将获取的支付请求发送到电子支付服务方;电子支付服务方完成相应的支付服务,并在必要时通过受理方转交或通知收款方电子支付支撑方提供账户管理、账务核算,安全措施与管理等功能,这些功能可能自某一方可以实现电子支付开始就已经提供,但收款方,付款方与受理方的人员可能不需知悉电子支付的概念如图1所示收款方接收受理方转交电子支付电子支付账个服务方支撑方付款方提交转交受理方注1:图中的受理方应看做一个实体,为便于理解,画作了分别连接的两个方框注2;收款方的受理方可能是隐含的,即实际上在电子支付服务方内部即完成了支付动作,收款方仅仅通过受理方获得了通知图1电子支付概念图
GB/I31502一2015 5.1.3电子支付系统模型在电子支付系统模型中,电子支付凭据、支付终端、支付安全前置,支付平台组成了电子支付系统，通过与用户和相应支付后台交互工作,并在必要时使用认证中心提供的身份认证服务,以完成电子支付交易电子支付系统模型如图2所示其与电子支付的映射关系一般为 a)付款方包括用户和电子支付凭据 b收款方可能包括用户和电子支付凭据,也可能仅为用户; 受理方包括支付终端和作为受理方操作员的用户; c 电子支付服务方包括支付安全前置、支付平台; d 电子支付支撑方包括支付后台和认证中心 e 认证中心电子支付系统评估对象(TOE 金融支付金融金融电子支付安全前置支付平台支付后台凭据载体用中介支付中介中介网络安全前置支付平台支付后台支付预存支付预存预存终端安全前置支付平台支付后台注1;图中用户是抽象的,为保持图的清晰性,未对角色及其操作的评估对象[ToE]组件进行进一步的划分注2:图中金融、中介,预存类支付安全前置、支付平台和支付后台都可能有多个受理方注3，图中的连接分为三类用户与电子支付凭据载体和支付终端连接的点线表示人机交互;电子支付凭据载体与支付终端以及支付终端与预存支付安全前置的点划线表示近场或接触;实线表示公共网络,但不限制网络连接的物理链路;双线箭头表示同一受理方TsF内部传送图中画出的六边形网络是为了便于描述支付终端、支付安全前置和认证中心的工作关系,并区别描述通过网络与通过近场或接触方式的连接注4:一个支付服务的提供实体,可仅支持图中的一种模式,也可同时支持图中的两种甚至三种模式,即同时承担几种不同方式的受理方注5:电子支付凭据载体,支付终端、支付安全前置,支付平台所构成的电子支付系统,其整体构成了一个分布式的评估对象[ToE] 注6，用户,支付后台和认证中心是电子支付系统模型的边界条件,非评估对象实体注7:安全芯片可能涉及电子支付系统中的每一个组件,按照本标准给出的模型描述安全芯片所在的组件以及在交互过程中安全芯片的作用,更易于理解安全芯片的功能、安全问题定义、安全目的,安全功能要求和安全保证要求图2电子支付系统模型
GB/T31502一2015 5.1.4评估对象[ToE实体 5.1.4.1电子支付凭据载体电子支付凭据载体是通过技术手段,存储安全属性和包括电子支付凭据在内的用户数据,并能够支持完成电子支付交易的介质注1:不同的电子支付凭据载体,其存储用户数据的方式,能力和安全属性不同随现代电子技术和工艺的高速发展,新型电子支付凭据载体的存储和计算能力日新月异,其功能与安全性可能会出现颠覆性变化注2:在同一个交易中,可能需要电子支付凭据持有者的电子支付凭据载体,也可能还需要受理方操作员的电子支付凭据载体示例，金融磁条卡,金融Ic卡,金融sD卡,金融sIM卡,动态密码器和UsBKey是不同形式的电子支付凭据载体金融磁条卡因其存储方式能力和安全属性的落后,已经在全世界公共电子支付领域逐渐被金融IC卡等带CPU的电子支付凭据载体所替代动态密码器在动态口令卡大规模应用后,出现了功能更强,更安全的接触型产品第一代UsB Key已过渡到带操作界面的第二代,带键盘第三代和基于生物识别技术的智能UsBKey也已出现 5.1.4.2支付终端支付终端是能读取或读写电子支付凭据载体、接受用户输人支付相关信息,发起电子支付的电子设备根据其安全识别可分为相对的专用支付终端和非专用支付终端,本标准TOE之内的支付终端不另说明的均为专用支付终端非专用支付终端接人电子支付系统,需要包括电子支付凭据载体在内的各种安全识别配合注1:根据支付终端的种类不同,用户可能仅是电子支付凭据持有者,也可能还包括受理方操作员注2各类支付终端连接的支付安全前置种类不同,其物理层,数据链路层和网络层的实现模式亦不相同注3:类比专用支付终端的初始化,非专用支付终端接人电子支付系统时需要数字证书认证个人常用支付终端可以绑定硬件示例:销售点终端(POs)、自动金融柜员机(ATM)是专用支付终端的例子;个人计算机(PC)、电视机顶盒(sTB)电话支付终端、移动电话支付终端是非专用支付终端的例子,这些设备与电子支付无关的功能在本标准中不做描述 5.1.43支付安全前置支付安全前置是设置于支付平台前的安全接口,其主要功能为 a)预防、减缓对支付平台和支付后台的攻击 b建立支付终端与支付平台之间的可信路径; e)建立支付平台与其他支付安全前置之间的可信路径示例1，预防,减缓对支付平台和支付后台攻击的例子,包括,但不限于防火墙、人侵检测,防病毒系统示例2:在支付终端与支付平台之间建立可信路径的例子,包括,但不限于VPN 支付安全前置可进一步划分为: 金融支付安全前置接收来自支付终端的交易请求,也可能接收来自中介支付安全前置的交 a 易请求,与金融支付平台进行信息交互中介支付安全前置接收来自支付终端的交易请求,与中介支付平台交互,并在需要时与金融 b 支付安全前置和[或]其他中介支付安全前置交互，预存支付安全前置接收来自支付终端的交易请求,与预存支付平台交互 5.1.4.4支付平台支付平台是电子支付的逻辑处理系统,接收支付终端通过支付安全前置发来的交易请求或交易记录,向支付后台发出动账请求并接收处理结果,形成对电子支付交易的响应,通过支付安全前置发送支付终端
GB/I31502一2015 支付平台可进一步划分为: 金融支付平台接收来自金融支付安全前置的交易请求,与金融支付后台进行信息交互中介支付平台接收来自中介支付安全前置的交易请求,按照预定的规则,与中介支付后台交互 ,并在需要时通过金融支付安全前置与金融支付平台交互,或通过其他中介支付安全前置与其他中介支付平台交互; 预存支付平台接收来自预存支付安全前置的交易请求,与预存支付后台交互注:中介支付平台可提供的交易双方的信用担保、降低网上交易风险、防止电子交易欺诈、增加网上交易成交率及提供其他相应的增值服务未在标准中描述示例1移动运背商广电运背商,石油供应商,自来水公司,电力公司,公共交通部门商业零售机构等商业机构均可能建立专用的预存支付平台与预存支付后台,以实现对预付款卡服务的按约定计量单位的计价扣收示例2;有效识别,评估、监测、控制和报告风险的例子,包括,但不限于;操作风险管理信息系统,可疑交易预警系统 5.1.5非评估对象[ToE实体 5.1.5.1用户用户是与电子支付系统交互以发起支付交易的实体,用户通过操作电子支付凭据载体与支付终端完成支付交易典型的用户包括: 电子支付凭据持有者提供电子支付凭据,并在必要时在支付终端上输人完成电子支付交易所需的信息,通过支付终端发起电子支付交易的用户; b)受理方操作员通过操作支付终端,按照业务规则初始化一个周期的电子交易环境,在电子支付交易时输人完成电子支付所需信息,通过支付终端发起电子支付交易的用户对一些自助终端,可能不需要受理方操作员的操作; 业务管理者通过操作支付终端、支付安全前置,支付平台和支付后台,进行业务参数配置、,业务异常调整、账务核算,清分,清算、产生业务状况报表的用户; 系统管理者通过操作电子支付凭据载体,支付终端、支付安全前置、支付平台,支付后台及其运行环境支撑设施,进行设备安装、维护,技术参数配置,设备运行环境与状况监控,保证电子支付系统正常运行的用户示例1:电子支付凭据持有者可能是持卡人、网上银行USBKey的持有人,手机银行动态密码器的持有人示例2;电子支付凭据持有者在支付终端上可能输人密码也可能采集生物特征示例3;受理方操作员在支付终端上可能签到、输人交易金额,也可能进行终端的结算示例4:业务管理者可能在支付平台上输人指令,以获得电子支付交易状况统计表示例5在支付过程中出现故障时,可能需要系统管理者的介人以正确完成支付行为 5.1.5.2支付后台支付后台是接收支付平台发出的动账请求并返回执行结果的系统这种动账请求可能是单笔模式的,也可能是批量模式的支付后台分为 a)金融支付后台其特征为: 保存有付款方的法定货币账户余额和交易明细 1) 2 能够对付款方账户进行动账处理，能够将电子支付交易发生额按照约定的规则分别存人收款方和电子支付相关方的账户 3) 4) 具有按照金融支付平台的请求或在金融支付后台本身发现核算错误时,进行账务调整的能力注1:经国家金融主管部门批准的金融机构才能设置金融支付后台
GB/T31502一2015 注2:付款方的账户一般是电子支付凭据持有者的账户,收款方的账户一般是受理方的账户除此之外的情况也是可能的,但会增加交易的复杂性示例:本条描述的金融支付后台是一个广泛的概念在实际交易中,付款方账户和收款方账户可能不属于同一个银行,但金融后台能在其内部完成这样的账户资金转移 b)中介支付后台其特征为: 保存有付款方、收款方和电子支付相关方的账户; 具有对付款方账户的动账能力,且将发生额暂时计人收款方和电子支付相关方的能力 2) 3》具有根据电子支付交易序列,对暂时计人收款方和电子支付相关方的发生额进行清分的能力; 具有根据电子支付交易序列,完成原支付交易的反向交易的能力 4) 5)具有根据电子支付交易序列,按照约定的规则对收款方账户进行动账的能力注1:经国家金融主管部门批准的第三方支付机构才能设置中介支付后台这是一种非银行金融服务,但在某些文献中,第三方支付服务也可能称作非金融支付服务注2:付款方的账户一般是电子支付凭据持有者的账户,收款方的账户一般是受理方的账户除此之外的情况也是可能的,但会增加交易的复杂性预存支付后台其特征为保存有付款方账户; 1 具有根据电子支付交易,对付款方账户进行动账的能力 2) 具有根据电子支付交易序列,完成原支付交易的反向交易的能力 3 注1;经国家主管部门批准的机构才能设置预存支付后台这也是一种非银行金融服务,但目前还没完全纳人金融管理,有部分与第三方支付服务重迭注2;付款方的账户一般是电子支付凭据持有者的账户除此之外的情况也是可能的,但会增加交易的复杂性示例:加油卡、购电卡、市政交通一卡通的后台系统为预存支付后台 5.1.5.3认证中心认证中心是经国家主管部门批准设立的具有权威性和公正性的第三方信任机构,负责在需要时签发和管理数字证书,提供身份认证服务注电子支付机构内部设立的认证中心,不能满足公共电子支付系统抗抵赖性的完整需求 5.2电子支付系统工作模式电子支付系统包括两种工作模式: 在线模式用户在支付终端上对电子支付凭据载体进行读[或读写]操作,在支付终端获取满足特定电子支付交易的全部必要信息后,通过网络向支付安全前置发出交易请求,随后金融支付安全前置将信息发送到金融支付平台,金融支付平台进行逻辑处理,向金融支付后台发出动账请求并获得结果后,通过金融支付安全前置向支付终端返回交易结果,完成电子支付交易中介支付安全前置将信息发送到本中介支付平台,本中介支付平台进行逻辑处理,向本中介支付后台发出动账请求,并;通过本中介支付安全前置、金融支付安全前置向金融支付平台发出交易请求,由金融支付平台向金融支付后台发出动账请求,取得处理结果后返回本中介支付平台;或[且]通过本中介支付安全前置,另一中介支付安全前置向另一中介支付平台发出交易请求,由另一中介支付平台向另一中介支付后台发出动账请求,取得处理结果后返回本中介支付平台由本中介支付平台处理后产生对电子支付交易的响应,返回支付终端,完成电子支付交易预存支付安全前置将信息发送到预存支付平台,预存支付平台进行逻辑处理,向预存支付
GB/I31502一2015 后台发出动账请求并获得结果后,通过预存支付安全前置向支付终端返回交易结果,完成电子支付交易注1:在线模式(onlinemode)也称为联机模式,联线模式注2:一般来说,通过中介支付服务方进行电子支付需要多次交易组成的交易序列,方可达到电子支付的目标离线模式用户在支付终端上对电子支付凭据载体进行读写操作以完成电子支付交易 b 随后支付终端通过网络连接金融支付安全前置,将交易记录发送到金融支付平台.金融支付 1 平台进行逻辑处理,向金融支付后台发出动账请求并获得结果,并依据结果形成后继处理信息在适宜的时刻,金融支付平台通过金融支付安全前置向支付终端发送后继处理信息支付终端通过网络或近场、物理通道连接预存支付安全前置,将交易记录发送到预存支付平台,预存支付平台进行逻辑处理,向预存支付后台发出动账请求并获得结果,并依据结果形成后继处理信息在适宜的时刻,预存支付平台通过预存支付安全前置向支付终端发送后继处理信息注:离线模式(oflinemode)也称为脱机模式示例:在离线模式下,止付名单(黑名单)就是一种后继处理信息电子支付系统的行为模型参见附录A 5.3受保护资产 5.3.1描述目的在本标谁的后面各章中所描述的安全同题描述、安全目的和安全需求,均为了保护5.3中所描述的受保护的资产 5.3.2用户数据[C userdat a门]类(PUD 5.3.2.1概述用户数据[userdata]是指由用户产生或为用户产生的数据,这些数据不影响电子支付系统安全功能的运行 5.3.2.2业务配置数据(PUDBCD) 电子支付凭据载体,支付终端,支付平台,支付后台的业务配置数据,与应用处理软件一同构成了业务处理规则.至少是一些主要的业务处理规则示例:在使用卡号和密码登录网上银行时,每日转账的最高限额为一个业务配置数据 5.3.2.3业务处理数据(PUDBPD) 电子支付凭据载体,支付终端,支付平台、支付后台的业务数据,包括电子支付系统在运行时处理以及由处理产生的各种业务信息注业务处理数据可根据管理需要分为客户信息,账户信息,交易记录,业务统计与业务支持等信息示例1:电子支付凭据持有者和受理方操作员的姓名、证件种类与号码、联系电话都是电子支付相关方人员的客户信息示例2:付款方账户的余额、可支付的限额均为电子支付相关方账户信息示例3;从交易中获取的硬件绑定标识,交易时间,交易金额、接人地区,登陆P转人/出机构等信息进行组合形成预警监控规则,用于逐笔业务的实时风险筛选,并确定预警,批准或拒绝交易请求
GB/T31502一2015 5.3.2.4输入数据(PUD_IND 电子支付交易过程中,人工输人的数据 5.3.2.5传输数据(PUDTSD) 传输数据包括 a)电子支付凭据载体与支付终端之间传输的数据; b) 支付终端与支付平台之间传输的数据 e)各支付服务方通过各自的支付安全前置传输的数据注:在支付服务方内交换的数据,例如同一服务方的支付平台和支付后台间交换的数据,或不同银行构成了一个金融支付后台而在内部交换的数据,未作为电子支付系统的传输数据考虑示例:交易的业务报文是电子支付凭据载体与支付终蹦之间和支付终端与支付平台之间传输的数据 5.3.3评估对象安全功能数据[IsFdata]类(PTD) 5.3.3.1概述评估对象安全功能数据[TSFdata]是指由电子支付系统产生或为电子支付系统产生的数据,这些数据可能会影响电子支付系统安全功能的运行 5.3.3.2评估对象安全功能[TS]受保护数据(PID_PRD 除系统的管理者和拥有者外,不允许改变内容但允许公开内容的数据注:不管是数据的非管理者用户还是数据的非拥有者用户,对评估对象安全功能[TSF]受保护数据的改变可能影响该评估对象[ToE]的运行安全,但对这类数据的泄露是可接受的示例:用户和设备的标识数据(ID)、用户或系统状态数据设备和网络状态信息和配置设置、设备安全状态等均为评估对象安全功能[TSF]受保护数据 5.3.3.3评估对象安全功能[Ts]保密数据(PIDcoD 除系统的管理者和拥有者外,既不允许改变内容也不允许公开内容的数据注:不管是数据的非管理者用户还是数据的非拥有者的用户,对评估对象安全功能[TSF]保密数据的改变和泄露均可能影响该评估对象[ToE的运行安全示例:用户和设备的鉴别数据,用户口令,审计记录数据、数字证书的私钥,访间控制表等均为评估对象[ToE]保密数据 5.3.4设计信息类(PDn 5.3.4.1概述设计信息类数据是指电子支付系统的设计、构建信息这些信息可能会影响电子支付系统安全运行,或可能会缩短电子支付系统能够安全运行的时间,或可能会减少电子支付系统安全运行的场合 5.3.4.2组件设计信息(PD1CD 在电子支付系统组件的设计过程中,设计的输人信息和期望的输出信息示例:设计规格说明、指令体系确认和验证设计出的组件实现了要求的功能、性能以及未实现未要求功能的方法及其数据示例:测试激励数据电子支付系统组件的设计过程中所涉及的物理元件,部件工艺、专用装备、测试设备的信息示例:芯片掩膜版,ROM掩膜数据生成工具、物理验证环境
GB/I31502一2015 5.3.4.3应用设计信息(D_ADn 应用设计信息是指电子支付系统的设计过程中,产生的为按需求进行应用设计涉及的设计信息示例:应用系统软件本身,安全功能策略数据,预个人化数据存储策略均为应用设计信息安全问题定义概述本章描述了电子支付系统可能面临的典型安全问题,针对由不同的组件构成的电子支付系统以及应用在不同场合的电子支付系统,在制定PP和ST时,应对本标准提出的典型安全问题进行分析,并补充在特定情况下可能出现的安全问题为了全面和易于理解地描述典型安全问题,并在编写不同组件的PP和sT时便于参照标准中的内容,本标准对不同组件面临的典型安全问题,采用的描述方式为: -完全等同的,采取不分组件的文字描述方式; 不完全等同的,采用分组件的文字描述方式; -除明确说明外,对各典型安全问题的描述未隐含相互引用关系 6.2威胁 6.2.1描述方式电子支付系统涉及三大类威胁;对用户数据的威胁,对安全功能数据的威胁,对设计信息的威胁描述威胁采用的统一格式;威胁主体(涉及;能力[知识与技术,工具]),威胁到的资产,威胁的负面作用在本标准中没有给出威胁主体的描述,在5.3“受保护资产”中已对威胁到的资产给出了相应的描述,因此可以如表2描述威胁表2威胁数据类型威胁受保护数据用户数据业务配置数据(PUDBCD 未经授权的泄露未经授权的变更 [userdata 业务处理数据(PUD_BPD) 未经授权的泄露未经授权的变更输人数据(PUDIND) 伪造未经授权的变更抵赖传输数据(PUD_TSD 伪造未经授权的变更抵赖安全功能数据[TsFdata 受保护的数据(PTDPRD) 伪造未经授权的变更保密数据(PD_coD) 伪造未经授权的泄露未经授权的变更伪造设计信息(PDD 组件设计信息(PDL_CD 未经授权的泄露未经授权的变更应用设计信息(PDL_AD 伪造未经授权的泄露未经授权的更改 1o
GB/I31502一2015 6.2.2对用户数据[userdata]的威胁(STU) 6.2.2.1对业务配置数据的威胁(SU_BcD 6.2.2.1.1未经授权的泄露(STUCD.1) 电子支付系统的业务配置数据,包括记载在软件代码中的业务配置数据、记载在数据库或文件系统中的业务配置数据或动态由配置管理软件发送到电子支付系统的业务配置数据,可能由于攻击者的恶意攻击或开发人员的疏漏,遭到未授权的泄露示例:客户进行动账交易时由电子支付系统下传的随机验证码规则过于简单被推算出来,即为未授权的泄露 6.2.2.1.2未经授权的变更(STU_BCD.2) 电子支付系统的业务配置数据,可能由于攻击者的恶意攻击或开发人员的疏漏,遭到未授权的变更,变更的方式可能包括更改原有的数据、删除原有数据或增加新的数据示例:客户进行动账交易时提交给电子支付系统的交易数据被截获并改变交易报文的主要内容,即为未经授权的变更 6.2.2.2对业务处理数据的威胁(SrUPBD) 6.2.2.2.1未经授权的泄露(STUPBD.1 电子支付系统的业务处理数据,可能由于攻击者的恶意攻击或开发人员的疏漏,遭到未授权的泄露示例，电子支付系统的业务处理数据所在的存储空间可能在被释放和重新分配之前未完全清除,导致业务处理数据的泄漏 6.2.2.2.2未经授权的变更(STU_PBD.2) 电子支付系统的业务处理数据,可能由于攻击者的恶意攻击或开发人员的疏漏,遭到未授权的变更,变更的方式可能包括更改原有的数据,删除原有数据或增加新的数据 6.2.2.3对输入数据的威胁(SU_IND 6.2.2.3.1伪造(STU_IND.1 电子支付系统的输人数据,可能由于攻击者的恶意攻击,开发人员的疏漏或用户的误操作,遭到伪造示例:在商户操作员没有在POos输人数据的情况下,POs认为接受到了输人数据,即为一种伪造 6.2.2.3.2抵赖(STU_IND.2) 电子支付系统的输人数据,可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作或恶意操作,遭到抵赖,抵赖的方式可能是输人方不承认输人过数据,也可能是接收方不承认接收到过数据示例:在商户操作员在P0OS输人数据的情况下,POS认为没有接受到输人数据,即为一种抵赖 6.2.2.3.3未经授权的变更(SrU_IND.3) 电子支付系统的输人数据,可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作,遭到未授权的变更示例:个人计算机接受到的输人数据与网上银行用户输人的数据不一致,且这种不一致并非电子支付系统在构造时设定的数据变换,即为一种未授权的变更 11
GB/I31502一2015 6.2.2.4对传输数据的威胁(STU_ISD) 6.2.2.4.1伪造(STU_TSD.1 电子支付系统的传输数据,可能由于攻击者的恶意攻击,开发人员的疏漏或用户的误操作,遣到伪造示例:在ATM经过金融支付安全前置向金融支付平台发出请求的情况下,在金融支付平台尚未向ATM返回响应信息时,ATM接收到了响应信息,即为一种传输数据的伪造 6.2.2.4.2未经授权的变更(STU_ITSD.21 电子支付系统的传输数据,可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作,遣到未授权的变更示例:支付平台接受到的传输数据与个人计算机发出的数据不一致，且这种不一致并非电子支付系统在构造时设定的数据变换,即为一种未授权的变更 6.2.2.4.3抵赖(STU_TSD3 电子支付系统的传输数据,可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作或恶意操作,遭到抵赖,抵赖的方式可能是发送方不承认发送过数据,也可能是接收方不承认接收到过数据 6.2.3对评估对象安全功能数据[TSFdata]的威胁(STP) 6.2.3.1对评估对象安全功能[TSF]受保护数据的威胁(STPPRD 6.2.3.1.1伪造(STPPRD.1) 电子支付系统的评估对象安全功能[TsF]受保护数据,可能由于攻击者的恶意攻击或开发人员的疏漏,遭到伪造示例:在ATM经过金融支付安全前置向金融支付平台发出请求的情况下,在金融支付平台尚未向ATM返回响应信息时,ATM接收到了响应信息,且响应信息的鉴别码能够为ATM确认,即为一种评估对象安全功能[TsF]受保护数据的伪造 6.2.3.1.2未经授权的变更(STPRD.2) 电子支付系统的评估对象安全功能[TSF]受保护数据,可能由于攻击者的恶意攻击或开发人员的疏漏,遭到未授权的变更示例当支付平台的交易记录带有鉴别码时,在未经过操作的交易修改交易记录的情况下,未通过允许的操作修改了鉴别码,且再通过允许的操作进行鉴别码的确认时可以通过,即为一种评估对象安全功能[TSF]受保护数据的未经授权的变更 6.2.3.2对评估对象安全功能[ISF]保密数据的威胁(STP_coD 6.2.3.2.1未经授权的泄露(STP_coD.1) 电子支付系统的评估对象安全功能[TSF]保密数据,可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作,遭到未经授权的泄露示例1:存储于中介支付平台的用户名称与密码明文的泄露,即为一种评估对象安全功能[TSF]保密数据的未经授权的泄露示例2:在网上电子支付交易中,在互联网上通过明文传输用户账户的口令,即为一种TSF保密数据的未经授权的泄露 12
GB/T31502一2015 示例3:当组件是IC卡芯片时,可能通过未授权使用新的或未发行的IC卡芯片而非法获得IC卡芯片信息,也可能会利用相关命令,尤其是测试和调试命令来获取Ic卡芯片安全功能数据或敏感的用户数据,这些命令在智能卡生命周期的以往某些阶段是必要的,但在现阶段是被禁止的示例4，当组件是1c卡芯片时,攻击者可能实施密码攻击或穷举攻击危及Ic卡芯片的安全功能这种攻击可能用到一些加密函数、编码/解码函数或随机数发生器攻击者的目标是发现密码算法中的脆弱性或通过穷举来发现密钥和输人数据 6.2.3.2.2伪造(SIPcoD.2) 电子支付系统的评估对象安全功能[TSF]保密数据,可能由于攻击者的恶意攻击或开发人员的疏漏,遭到伪造示例1:在中介支付平台A与金融支付平台B之间约定以加密方式交换支付信息时,若在中介支付平台A未向金融支付平台B发起请求报文,而金融支付平台B接收到请求报文,且经过解密能正确解析报文时,即为一种评估对象安全功能[TSF数据的伪造示例2;假定中介支付平台A采用证书手段对其客户的交易进行加密,且证书应为某第三方机构发放,若中介支付平台A接收到的交易请求采用某证书对交易进行了加密,且经解密和业务解析后认为内容正确,但交易的发起方并未从第三方机构获得上述证书,即为一种评估对象安全功能[TsF数据的伪造 6.2.3.2.3未经授权的变更(SIPcoD.3) 电子支付系统的评估对象安全功能[TSF]保密数据,可能由于攻击者的恶意攻击、开发人员的疏漏或用户的误操作,遭到未授权的变更示例:当支付平台中的客户交易密码以密文的方式存储,但被进行了修改,且修改后的密文可被正确解密并成为另外的明文,即为一种未经授权的变更 6.2.4对设计信息的威胁(STD) 6.2.4.1对组件设计信息的威胁(STD_cDn) 6.2.4.1.1未经授权的泄露(SIPCD1.1) 电子支付系统的组件设计信息,可能由于攻击者的恶意攻击、开发人员的疏漏,遭到未经授权的泄露注:泄漏方式可能有缺陷插人、错误插人、未授权程序装载、反汇编和反编译、物理探测等示例1;当组件是Ic卡芯片时,物理探测可能是利用c卡芯片失败性分析和采用半导体逆向工程技术来从c卡芯片中获取数据这种探测可能包括对电气功能的探测由于这种探测需要直接接触Ic卡芯片内部,所以仍把它归为物理探测攻击者的目的是获取诸如硬件安全机制、访问控制机制、鉴别系统、数据保护系统、存储器分区,以及密码算法程序等设计细节弄清软件设计中谱如初始化数据、个人化数据、口令或钥等也是他们的目标 lc卡芯片可能会在未上电或已上电状态下受到探测攻击并且在遭受这样的攻击后可能会处于无法操作状态示例2电子支付系统组件的设计规格说明的扩散超出了必须的范围,即为一种组件设计信息的未经授权的泄露 6.2.4.1.2未经授权的变更(STDCDI.2 电子支付系统的组件设计信息,可能由于攻击者的恶意攻击、开发人员的疏漏,遭到未授权的变更示例1:当组件是IC卡芯片时,对IC卡芯片的物理更改可能是利用IC卡芯片失效性分析或采用半导体逆向工程技术来实现攻击者的目的是获取诸如硬件安全机制,访问控制机制,鉴别系统、数据保护系统,存储器分区,以及密码算法程序等设计细节弄清软件设计中诸如初始化数据、个人化数据、口令或密钥等也是他们的目标更进一步的目标可能是修改或操纵调试阶段的锁定操作、初次使用标记、卡使用锁定、锁定功能配置、卡锁定标志、卡终止标志等,以便非法使用IC卡芯片以获取IC卡芯片的设计信息和操作内容、或者改变安全功能及安全功能数据示例2;当组件是Ic卡芯片时,攻击者可能通过反复地插人选定的数据,并观察相应的输出结果,从而获得Ic卡 13
GB/I31502一2015 芯片安全功能或用户相关的信息这种威胁的特点是有目的选择和控制输人数据,而不是随机选择或控制通过插人选定的数据并观察输出结果的变化,是对密码设备的一种常见攻击手段其目的是通过观察Ic卡芯片如何对选定的输人做出响应,来获取与安全功能或用户相关的信息这种威胁的特点是有意选择和控制输人数据,而不是随机选择数据或控制输人输出操作中的物理特性示例3，当组件是1c卡芯片时,攻击者可能通过引人无效的输人数据来危及Ic卡芯片的安全功能数据的安全错误输人操作形式包括错误的格式、索要的信息超过记录范围,试图找到并执行无正式书面文件的命令这样的输人可能在正常使用过程中的任意时间发生,包括访问授权前其结果是该攻击可能会危及安全功能、在操作中产生可利用的错误或者泄漏所保护的数据示例4:当组件是IC卡芯片时,攻击者可能利用未授权的程序探测或修改I卡芯片安全功能代码及数据每个授权角色都有特定的权限仅用于下载指定的程序未授权程序可能包括在正常操作期间不希望执行的合法程序,也可能包括用于有意刺探或修改Ic卡芯片安全功能的未授权装载程序 6.2.4.1.3仿造(STDCD1.3 电子支付系统的组件设计信息,可能由于攻击者的恶意攻击、开发人员的疏漏,遭到仿造示例:电子支付系统的某一组件不是按照授权的程序产生的,但是可以应用于电子支付系统并正常工作,即为一种组件设计信息的仿造需要说明的是,仿造的组件可能可以完成全部要求的功能,但是不能排除完成了不应具备的功能,例如在完成对用户密码加解密的同时,再加密并保存了用户密码的明文的副本 6.2.4.2对应用设计信息的威胁(STPD) 6.2.4.2.1未经授权的泄露(STPPD1.1) 电子支付系统的应用设计信息,可能由于攻击者的恶意攻击、开发人员的疏漏,遭到未经授权的泄露示例电子支付系统应用的源代码的扩散超出了必须的范围,即为一种应用设计信息的未经授权的泄露 6.2.4.2.2未经授权的变更(STDPDI.2 电子支付系统的应用设计信息,可能由于攻击者的恶意攻击,开发人员的疏漏,遭到未授权的变更示例安全功能策略数据的变更未按规定的程序进行授权,即为一种应用设计信息的未经授权的变更 6.2.4.2.3仿造(STDPDI.3) 电子支付系统的应用设计信息,可能由于攻击者的恶意攻击、开发人员的疏漏,遭到仿造注:仿造的系统不一定能够完成电子支付系统的全部有效功能示例:钓鱼网站即为一种对应用设计信息的仿造 6.3组织安全策略(soP) 6.3.1概述电子支付系统的组织安全策略(OsP)是要由该TOE、它的运行环境和它们组合来执行电子支付系统的组织安全策略(OsP)是电子支付系统的安全规则、规程或指导,它们是由一个实际组织现在和/或未来就系统运行环境所强加的或假定的一个组织对TOE运行环境的控制可以依靠该组织安全策略(OSP),或执法机构可以依靠该组织安全策略(OSP) 电子支付系统的组织安全策略 OsSP)可应用到电子支付系统的ToE和/或该TOE的运行环境例如: -所有用于公众电子支付系统组件的产品均必须符合有关口令生成和加密的国家标准只允许具有系统管理员授权的用户才能管理电子支付系统的服务器 -对电子支付系统基本级的安全事件具有可核查性 14
GB/T31502一2015 -电子支付系统能按规约的事件模式捕获安全事件,并发出相应的警告 6.3.2操作得到授权(soP_oAU 6.3.2.1业务管理者和系统管理者在电子支付凭据载体的操作(soP_oAu.1 电子支付凭据载体需要业务管理者和系统管理者操作时,业务管理者和系统管理者应仅当在得到操作该支付凭据载体的授权后才能进行操作示例:电子支付凭据载体的初始化操作必须经过严格的授权 6.3.2.2受理方操作员在支付终端操作(soPoAU.2) 对有受理方操作员操作的支付终端,受理方操作员应仅当在得到操作该支付终端的授权后才能操作该支付终端 6.3.2.3业务管理者和系统管理者在支付终端的操作(soPoAU.3) 对有业务管理者和系统管理者操作的支付终端,业务管理者和系统管理者应仅当在得到操作该支付终端的授权后才能操作该支付终端 6.3.2.4支付安全前置和/或支付平台操作得到授权(soPoAU.4 支付安全前置和/或支付平台操作的用户,应仅当在得到操作支付安全前置和/或支付平台的授权后才能操作支付安全前置和/或支付平台 6.3.3安全事件审计(SsoPsIA 6.3.3.1支付凭据载体的安全事件审计(soPSIA.1) 对具备能力的支付凭据载体,应产生并维护可提供有关支付凭据使用与安全有关事件的审计明细的记录,保护这样的记录免遭未授权地泄露或更改,并应由授权人予以评审示例:IC卡是一种具备能力的安全支付凭据载体;而磁条卡是一种不具备能力的支付凭据载体 6.3.3.2支付终端的安全事件审计(soPsIA.2) 对具备能力的支付终端,应产生并维护可提供有关支付终端使用与安全有关事件的审计明细的记录,保护这样的记录免遭未授权地泄露或更改,并应由授权人予以评审示例;ATM是一种具备能力的支付终端;个人计算机是一种不具备能力的支付终淄,特别是当计算机的记忆器件例如硬盘、静态存储器)进行信息消除后,将使所有的记录消失带键盘、记忆器件的支付凭据载体-高安全等级USB Key作为个人计算机的配件使用时,形成一种具备能力的支付终端手机也是一种不具备能力的支付终端,特别是当手机记忆器件例如存储器)进行信息消除后,将使所有的记录消失带记忆器件的支付凭据载体-接触型动态密码器作为手机的配件使用时,形成一种具备能力的支付终端 6.3.3.3支付安全前置和/或支付平台的安全事件审计(soPSIA.3 支付安全前置和支付平台应产生并维护可提供有关支付凭据使用与安全有关事件的审计明细的记录,保护这样的记录免遭未授权地泄露或更改,并应由授权人予以评审 6.3.4连接安全控制(SoPLNK 6.3.4.1支付终端与支付安全前置的连接控制(soPLNK.1) 对支持安全事件审计的支付终端,其连接到支付安全前置应受支付安全前置和支付平台的控制,以 15
GB/I31502一2015 防止未授权的连接和使用示例:对ATM连接支付安全前置应进行控制;而对机顶盒连接到支付安全前置则不必进行控制;同一支付终端可连接到不同的支付安全前置,但不应在两个支付安全前置之间构成信道 6.3.4.2支付安全前置间的连接控制(soPLNK.2) 不同支付服务方的支付安全前置的连接应受到连接的支付安全前置或支付平台各自的控制,以防止未授权的连接和使用 6.3.43支付平台间的连接控制(SoPLNK.3 不同支付服务方支付平台之间仅应通过各自支付安全前置连接,不应直接进行连接 6.3.5业务管理控制(SoPBMC) 6.3.5.1支付终端业务管理控制(SoPBC.1 对支持安全事件审记的支付终端,只有业务管理者才能通过操作支付终端,进行业务参数配置、业务异常调整、产生业务状况报表等操作 6.3.5.2支付安全前置与支付平台业务管理控制(soPBC.2) 只有业务管理者才能通过操作支付安全前置与支付平台,进行业务参数配置,业务异常调整、账务核算、清分、清算、产生业务状况报表等操作 6.3.6系统管理控制(SoPSc 6.3.6.1支付终端系统管理控制(soPSc.1)y 对支持安全事件审记的支付终端,只有系统管理者才能通过操作支付终端,进行设备技术参数配置等操作 6.3.6.2支付安全前置与支付平台系统管理控制(soPSMC.2 只有系统管理者才能通过操作支付安全前置与支付平台,进行设备技术参数配置、设备运行环境与状况监控等操作 6.3.7基础设施安全(soPIs) 6.3.7.1操作系统的安全(SoP_IFS.1 支撑评估对象[TOE]运行的操作系统,应达到可接受的最低安全要求 6.3.7.2数据库的安全(soPIS.2) 支撑评估对象[ToE]运行的数据库,应达到可接受的最低安全要求 6.3.7.3防火墙的安全(soPIs.3) 支撑评估对象[TOE]运行的防火墙,应达到可接受的最低安全要求 6.3.7.4路由器的安全(soP_IFS.4 支撑评估对象[TOE]运行的路由器,应达到可接受的最低安全要求 16
GB/T31502一2015 6.3.8网络通信的安全(soPNCS TOE内部能够建立可信路径 TOE与银行后台和CA认证中心之间能够建立可信信道 6.4 假设(SAS 6.4.1概述有关电子支付系统运行环境所做出的假定,其目的是使ToE有能力提供安全功能如果ToE放在一个不满足这些假定的运行环境中,那么该TOE就不可能提供它的所有安全功能这样的假定可以是有关该运行环境的物理方面、人员方面和连接方面注意;在评估期间,这些假定均被认为是真的,即对它们不做任何方式的测试出于这一理由,假定仅是关于运行环境而做出的假定决不可能有关TOE的行为而做出,因为一个评估是由有关该TOE 的评估断言所组成的,并且不能假定有关TOE是真的断言支付安全前置和支付平台都应放置在一个物理安全的环境之中,即使在出现物理意外事件的情况下,包括电磁辐射,也能够降低对运行支付安全前置和支付平台的硬件设备的影响 6.4.2设计信息文档安全SAs_DIS 电子支付系统各组件的设计信息文档都应是安全可控的 6.4.3实体安全(SASAPS) 6.4.3.1支付安全前置与支付平台实体安全(SAsAPs.1) 支付安全前置和支付平台都应放置在一个物理安全的环境之中,即使在出现物理意外事件的情况下,包括电磁辐射,也能够降低对运行支付安全前置和支付平台的硬件设备的影响 6.4.3.2支付安全前置与支付平台的物理访问控制(sAs_As.2 支付安全前置和支付平台的管理员终端应放置在一个受控访问的区域 6.4.4支付后台和认证中心可信(SAs_BcI 支付后台和认证中心符合国家相关监管规定,始终是可信的 6.5安全问题定义理由安全问题定义对受保护资产的对应关系,见附录安全目的 7.1概述本章是针对电子支付系统的威胁、OSP等安全问题所给出的解决方案描述了针对电子支付系统典型安全问题的典型安全目的,针对由不同的组件构成的电子支付系统以及应用在不同场合的电子支付系统组件,在制定PP和ST时,应针对剪裁的安全问题定义分析本标准提出的典型安全目的,对补充的安全问题定义补充安全目的为了全面和易于理解描述典型安全目的,并在编写不同组件的PP和ST时便于参照标准中的内容,本标准对不同组件面临的典型安全目的,采用的描述方式为 17
GB/I31502一2015 -完全等同的,采取不分组件的文字描述方式; -不完全等同的,采用分组件的文字描述方式; -除明确说明外,对各典型安全目的的描述未隐含相互引用关系 7.2针对评估对象[IoE]的安全目的(oEr) 7.2.1防止业务配置数据和业务处理数据未授权的泄露和变更(oETBCL) 电子支付系统各组件均应保护业务配置数据和业务处理数据,以免未经授权泄露和更改示例1;对用户进行标识与鉴别示例2;对不同的操作划分不同的用户权限 7.2.2防止输入数据和传输数据的伪造、抵赖和未授权变更(oET_IND 电子支付系统各组件均应保护输人数据和传输数据,以免伪造,抵赖和未授权变更注1:信息传输应对通信方进行标识和鉴别,其中的标识应可与事先的设置进行比对当支付平台和支付后台在物理上部署于同一环境时,其对通信方的标识和鉴别可采用不同于网络传输时标识和鉴别的方式进行,也可不再鉴别传输数据注2:信息传输应正确鉴别传输数据但不同组件在物理上部署于同一环境时,其对通信方的标识和鉴别可采用不同于网络传输时标识和鉴别的方式进行,也可不再鉴别传输数据 7.2.3防止受保护数据和保密数据伪造和未经授权的变更(oETBP 电子支付系统各组件均应保护受保护数据和保密数据,以免伪造和未经授权变更 7.2.4防止Ts保密数据泄露(oE:_Pc' 电子支付系统各组件均应保护TSF保密数据以免未经授权泄露 7.2.5防止设计信息伪造和未经授权的泄露、变更(oE！_PBD 电子支付系统各组件均应保护设计信息,以免伪造和未经授权的泄露、变更注在进行电子支付系统各组件的初始化中,应基于基础硬软件支持,植人发行者特定的鉴别信息 7.2.6产生安全日志(oET_GSsL) 电子支付系统各组件的基础硬软件和业务软件支持的,均应对所有的涉及电子支付交易的事件和安全事件产生日志,并防止伪造,未经授权泄露或变更 7.3针对评估对象[IoE]运行环境的安全目的(oTE) 7.3.1网络通信的安全(oET_Ncs) TOE内部应使用可信路径 ToE与银行后台和cA认证中心之间应使用可信信道 7.3.2安全目的理由安全目的与安全问题定义之间的应对关系,见附录C 注，建立可追踪性可使得本标准的阅读者便于判断是否所有的安全问题定义都被安全目的所覆盖,以及是否存在不针对安全问题定义的安全目的 18
GB/I31502一2015 安全功能要求 8.1 概述本章描述了电子支付系统针对典型安全目的的典型安全功能要求针对GB/T18336.l一2008中 5.4.1.3.2组件允许的操作,方括号【】中的黑体字表示已经完成的操作,斜体字加下划线表示需在编制 PP和ST时定义的赋值及选择针对由不同的组件构成的电子支付系统以及应用在不同场合的电子支付系统,在制定PP和ST 时,应针对剪裁的安全目的分析本标准提出的典型安全功能要求,对补充的安全目的定义补充的安全功能要求,并在必要时定义扩充的安全功能要求组件为在编写不同的电子支付系统和[或]其组件的PP和T时便于参照标准中的内容,本章采用了如下方式进行描述 a)显式地引用了GB/T18336.2一2008中要求的安全功能要求; 在需要时,给出了电子支付系统对安全功能要求的注释; b e给出了适用情况和取值建议 d)给出了应用的示例,这些示例作为一个独立的列项进行描述 8.2安全审计(FAU类) 8.2.1安全审计数据的产生 8.2.1.1审计数据产生(FAU_GEN.1) 8.2.1.1.1要求描述 FAU_GEN.1.1TsF应能为下述可审计事件产生审计记录: a)审计功能的开启和关闭; b) 有关基本级审计级别的所有可审计事件【赋值;基他专门定义的可市计事件】 c) FAU_GEN.1.2TSF应在每个审计记录中至少记录下列信息 a)事件的时间、事件类型、主体身份、用户操作、事件的结果(成功或失败); 对每种审计事件类型,基于PP或ST中功能组件的可审计事件定义.【赋值;其他市让相关 b 信息】. 8.2.1.1.2适用情况一个完整的电子支付系统的PP和[或]sT; a b)具备审计信息记录能力的电子支付系统组件的PP和[或]ST 示例:当ToE为磁条卡时.其作为电子支付凭据载体不具备审计信息的记录能力;而ToE为IC卡时.其作为电子支付凭据载体则具备审计信息的记录能力 8.2.1.1.3取值建议 a 对基本级的取值建议如下: 应针对每个需要审计的安全功能需求,按照GB/T18336.2一2008的要求进行选取注在GB/T18336.2一2008中,每个安全功能要求族均给出了有关审计的要求,并给出了可用的审计级别. 对赋值:其他专门定义的可审计事件】的取值建议如下: 19
GB/I31502一2015 1考虑到电子支付系统的交易量与系统复杂程度,宜根据风险程度确定其他专门定义的可审计事件示例:对支付金融金额达到某一限额的交易,可能记比未达到限额的交易更多的可供审计的信息在技术实现时,在可能的情况下,应根据实现环境提供对专门定义的可审计事件的扩展性 2 示例:在使用关系数据库时,可预留varchar类型的字段,而对记录在该字段中的内容进行有序组织 b)对详细级的取值建议如下 1 应在对事件类型进行划分的基础上,确定除FAU_GEN.1.2a)之外所有需要的信息 2 考虑到电子支付系统的交易量与系统复杂程度,宜根据风险程度确定其他审计相关信息示例:对支付金融金额达到某一限额的交易,可能记载比未达到限额的交易更多的可供审计的信息 8.2.1.1.4应用示例定义为一些记录在TSF控制下安全相关事件发生情况的需求识别审计的级别,列举TsF可审计的时间类型,以及识别在各种审计记录内用提供的审计相关信息的最小集合从属于;无其他组件依赖关系;FPTSTM.1可信时间戳 8.2.1.1.5电子支付凭据载体当电子支付凭据载体具备能力时示例1;当电子支付凭据是磁条卡时,不具备产生审计记录的能力示例2:当电子支付凭据载体是IC卡时,对在封闭环境使用的,宜选择不低于基本级;对在开放环境使用且IC卡具备能力的,宜选择详细级示例3:对移动支付的SD卡，一个其他专门定义的可审计事件的例子是访向问权限和能力的分配或撤销,例如是否可以在公交车上刷卡示例4;一种能够采用加密后存储数字证书,具有相应加解密能力的硬件设备,也可能不具备审计能力 FAU_GEN.1.2电子支付凭据载体应在每个审计记录中至少记录下列信息事件的时间、事件类型、主体身份、事件的结果(成功或失败); a b)对每种审计事件类型是基于保护轮廓或安全目标文档中安全功能要求组件的可审计事件进行定义的,【赋值;其他市计组关信息】示例;当电子支付凭据载体是金融Ic卡或金融sIM卡或UsBKey时,其他审计相关信息包括;PIN码连续错误次数.PIN码累计失败次数 8.2.1.1.6支付终端 FAU_GEN.1.1支付终端安全功能应能为下述可审计事件产生审计记录审计功能的开启和关闭 a 有关【选择;想据支付终端的能力私支持的业务确定最小级、基本级、崖细级之】审计级别的 b 所有可审计事件; 赋值;支付终端的初始化操作其他专门定义的可审事】 c 示例1:当支付终端是查询终端、专用代激费终端,宜选择不低于基本级;当支付终端是ATM,自助支付终端,POs 终端,宜选择详细级示例2:对代缴费终端，一个其他专门定义的可审计事件的例子是访问权限和能力的分配或撤销,例如是否可以接受贷记卡应用 FAU_GEN.1.2支付终端应在每个审计记录中至少记录下列信息事件的时间、事件类型、主体身份、事件的结果(成功或失败); a 2o0
GB/T31502一2015 b对每种审计事件类型是基于保护轮廓或安全目标文档中安全功能要求组件的可审计事件进行定义的,【赋值;其他审计相关信息】示例;当支付终端是PO05终端、自助支付终端;其他审计相关信息包括;操作员身份,机具唯一标识,安全部件唯一标识、事件安全等级,事件记录不可否认性签名 8.2.1.1.7支付安全前置 FAU_GEN.1.1支付安全前置安全功能应能为下述可审计事件产生审计记录 a)审计功能的开启和关闭有关【选择;据支付安全前置的能力初支持的业务确定最小级,基本级,详绷级之-】审计级 b 别的所有可审计事件; [赋值;支付安全前置的初始化操作,其他专门定义的可市计事佳】. c) 示例:对PSTN支付安全前置;一个其他专门定义的可审计事件的例子是;验证支付终端的电话号码是否为绑定号码 FAU.GEN.1.2支付终端应在每个审计记录中至少记录下列信息事件的时间、事件类型、主体身份、事件的结果(成功或失败); a 对每种审计事件类型是基于保护轮廓或安全目标文档中安全功能要求组件的可审计事件进 b 行定义的.【赋值其他审计相关信息】示例:当支付安全前置是PSTN支付安全前置;其他审计相关信息包括:接人的支付终端所使用的电话号码、操作员身份唯一标识、线路占用时间 8.2.1.1.8支付平台 FAU_GEN.1.1支付平台安全功能应能为下述可审计事件产生审计记录 a)审计功能的开启和关闭 b) 有关【选择;想据支付平台的能力和支持的业务确定最小级、基本级、详细级之-】审计级别的所有可审计事件; 【赋值;支付平台的初始化操作,其他专门定义的可审计事件】 c) 示例1;当支付平台是小范围,宜选择不低于基本级;当支付平台是大范围使用,宜选择详细级示例2;对网银业务支付平台,POs支付平台个其他专门定义的可市计事件的例子是绑定账户同日累计转出金额、转账交易数据签名、操作员签到口令连续错误次数、.操作员签到口令累计错误次数 FAU_GEN.1.2支付平台应在每个审计记录中至少记录下列信息: a)事件的时间、事件类型,主体身份,事件的结果(成功或失败); b)对每种审计事件类型是基于保护轮廓或安全目标文档中安全功能要求组件的可审计事件进行定义的,【赋值:其他审计相关信息】. 示例:当支付平台是rOs支付平台.ATM支付平台;其他审计相关信息包括;操作员身份唯一标识,.设备身份唯一标识注，本标准使用者对市计日志保存时间应遵从法律法规、国家监管要求,根据本标准使用者的商业利益需求而定 8.2.1.2用户身份关联(FAU_GEN.2) 8.2.1.2.1应用示例从属于;无其他组件依赖于:FAU_GEN.1审计数据产生; FIA_UID.1标识的时机 21
GB/I31502一2015 8.2.1.2.2 电子支付凭据载体 FAU_GEN.2.1当电子支付凭据载体具备产生审计记录的能力时,电子支付凭据载体安全功能应能将每个可审计的事件与引起该事件的用户身份相关联示例:磁条卡是不具备能力的电子支付凭据载体的例子;金融lIC卡是具备能力的电子支付凭据载体的例子 8.2.1.2.3支付终端 FAU_GEN.2.1支付终端安全功能应能将每个可审计的事件与引起该事件的用户身份相关联注:在一个交易中涉及多用户的,应分别关联每个用户的身份 8.2.1.2.4支付安全前置 FAUGEN.2.1支付安全前置安全功能应能将每个可审计的事件与引起该事件的用户身份相关联 8.2.1.2.5支付平台 FAU_GEN.2.1支付平台安全功能应能将每个可审计的事件与引起该事件的用户身份相关联 8.2.2安全审计评审 8.2.2.1审计查阅(FAUSAR.1 8.2.2.1.1电子支付凭据载体当电子支付凭据载体具备能力时 FAUSAR.1.1电子支付凭据载体安全功能应为【赋值;授权用户】提供从审计记录中读取【赋值审计信息列表】的能力 FAUSAR.1.2电子支付凭据载体安全功能应以便于用户理解的方式提供审计记录示例1:当电子支付凭据载体是IC卡,UsBKey;授权用户包括;电子支付凭据载体的所有者、支付终端示例2当电子支付凭据载体是;lc卡,UsBKey;审计信息列表包括,PN码验证连续错误次数,PIN码验证累计错误次数 8.2.2.1.2支付终端当支付终端具备能力时 FAU_SAR.1.1支付终端安全功能应为【赋值;授权用户】提供从审计记录中读取【赋值;审计信息列表】的能力 FAUSAR.1.2支付终端安全功能应以便于用户理解的方式提供审计记录示例1，当支付终端是;POS机自助支付终端;授权用户包括;操作员银行指定的设备管理员示例2:当支付终端是;POS机、自助支付终端;审计信息列表包括;操作员认证失败、用户认证失败、与支付安全前置身份认证失败、检测到非法代码,检测到非法通讯 8.2.2.1.3支付安全前置 FAU_SAR.1.1支付安全前置安全功能应为【赋值:授权用户】提供从审计记录中读取【赋值:审计信息列表】的能力 FAU_SAR.1.2支付安全前置安全功能应以便于用户理解的方式提供审计记录示例1:当支付安全前置是;PSTN支付安全前置;授权用户包括;操作员、审计员示例2:当支付安全前置是;PSTN支付安全前置;审计信息列表包括;对支付终端身份验证失败、支付终端使用未 22
GB/I31502一2015 经准许的接人号码、从同一支付终端连续两次接收到相同的数据报文 8.2.2.1.4支付平台 FAU_SAR.1.1支付平台安全功能应为【赋值;授权用户】提供从审计记录中读取【赋值:审计信息列表】的能力 FAU_SAR.1.2支付平台安全功能应以便于用户理解的方式提供审计记录示例1，当支付平台是;自助业务平台,网银业务平台;授权用户包括;操作员,审计员示例2:当支付平台是;自助业务平台、网银业务平台;审计信息列表包括;支付密码验证失败、当日累计转出金额超限的账户,对交易数据签名验签失败 8.2.2.2限制审计查阅(FAU_SAR.2) FAU_SAR.2.1除明确准许读访问的用户外,电子支付系统各组件安全功能均应禁止所有用户对审计记录的读访问 8.2.2.3可选审计查阅(FAU_SAR.3 支付安全前置 8.2.2.3.1 FAU_SAR.3.1支付安全前置安全功能应根据【赋值:具有逻辑关系的准则】提供从审计数据中进行【选择:搜索、分类、排序】的能力示例，当支付安全前置是PSTN支付安全前置;具有逻辑关系的准则包括;支付终端唯一身份标识,操作员唯一身份标识、电话号码,时间、安全事件等级,同时需要提供搜索,分类、排序之组合、按时间段、按操作员、按安全事件等级的能力 8.2.2.3.2支付平台 FAUSAR.3.1支付平台安全功能应根据【赋值:具有逻辑关系的准则】提供从审计数据中进行【选择;搜索,分类,排序】的能力示例;当支付平台是;自助支付平台,POs支付平台;具有逻辑关系的准则包括;用户账户,交易类别、安全事件等级、安全事件类别、时间;同时需要提供搜索,分类、排序之组合、按时间段、按账户,按交易类别按安全事件类别、按安全事件等级的能力 8.2.3安全审计事件存储 8.2.3.1受保护的审计迹存储(FAU_SIG.1) 8.2.3.1.1电子支付凭据载体当电子支付凭据载体具备能力时 FAUsTG.1.1电子支付凭据载体安全功能应保护所存储的审计记录,以避免未授权的删除 FAUsTG.1.2电子支付凭据载体安全功能应能【选择;防】对审计迹中所存审计记录的未授权修改 8.2.3.1.2支付终端 FAU_STG.l.1支付终端安全功能应保护所存储的审计记录,以避免未授权的删除 FAU_sTG.1.2支付终端安全功能应能【选择;防止】对审计迹中所存审计记录的未授权修改示例:当支付终端是;POS终端、自助支付终端、ATM时,选择防止 23
GB/I31502一2015 8.2.3.1.3支付安全前置 FAU_STG.1.1支付安全前置安全功能应保护所存储的审计记录,以避免未授权的删除 FAU_STG.1.2支付安全前置安全功能应能【选择:防止】对审计迹中所存审计记录的未授权修改 8.2.3.1.4 支付平台 FAU_STG.1.1支付安全前置安全功能应保护所存储的审计记录,以避免未授权的删除 FAU_STG.1.2支付安全前置安全功能应能选择:防止】对审计迹中所存审计记录的未授权修改 8.2.3.2审计数据可用性保证(FAU_sIG.2) 8.2.3.2.1电子支付凭据载体当电子支付凭据载体具备能力时 FAU_STG.2.1电子支付凭据载体安全功能应保护所存储的审计记录,以避免未授权的删除 FAUsTG.2.2电子支付凭据载体安全功能应能【选择防止】对审计迹中所存审计记录的未授权修改 FAU_STG.2.3当下列情况发生时.【选择,审计存储耗尽】,电子支付凭据载体安全功能应确保【赋值:已经产生的】审计记录将维持有效 8.2.3.2.2支付终端 FAU_sTG.2.1支付终端安全功能应保护所存储的审计记录,以避免未授权的删除 FAU_STG.2.2支付终端安全功能应能【选择防止】对审计迹中所存审计记录的未授权修改 FAUsTG.2.3当下列情况发生时【选择;审计存储耗尽】,支付终端安全功能应确保【赋值;保存审计记录的度量】审计记录将维持有效示例1对于支付终端,选择防止对审计迹中所存审计记录的未授权修改示例2:当支付终端的审计存储耗尽,保存审计记录的度量的一个例子是;按时间顺序新产生的审计记录,属于高级别安全事件的审计记录. 8.2.3.2.3 支付安全前置 FAU_STG.,2.1支付安全前置安全功能应保护所存储的审计记录,以避免未授权的删除 FAU_sTG.2.2支付安全前置安全功能应能【选择;防止】对审计迹中所存审计记录的未授权修改 FAU_STG.2.3当下列情况发生时【选择审计存储耗尽】,支付安全前置安全功能应确保【赋值已经产生的】审计记录将维持 a 有效; 【选择;失效、受攻击】支付安全前置安全功能应确保【赋值:堡在审记录的度】审计记录 b 将维持有效示例1;当支付安全前置的审计存储耗尽,保存审计记录的度量的一个例子是;按时间顺序新产生的审计记录,属于高级别安全事件的审计记录示例2:当支付安全前置失效或受攻击时,保存审计记录的度量的一个例子是已经备份的审计记录 8.2.3.2.4支付平台 FAUSTG.2.1支付平台安全功能应保护所存储的审计记录,以避免未授权的删除 FAU_STG.2.2支付平台安全功能应能【选择,选择一个;检测】对审计迹中所存审计记录的未授权修改 24
GB/T31502一2015 FAU_STG.2.3当下列情况发生时: 【选择:审计存储耗尽】,支付平台安全功能应确保【赋值:已经产生的】审计记录将维持有效 a b【选择;失效、受攻击】,支付平台安全功能应确保【赋值:保存审计记录的度量】审计记录将维持有效示例:当支付平台失效或受攻击时,保存审计记录的度量的一个例子是已经备份的审计记录 8.2.3.3审计数据可能丢失时的行为(FAU_sIG.3) 电子支付凭据载体 8.2.3.3.1 当电子支付凭据载体具备能力时 FAU_STG.3.！如果审计迹超过【赋值;颜定的眼度】电子支付凭据载体安全功能应采取【赋值;逝计存储可能失效时所采取的行为】示例，当电子支付凭据载体是Ic卡时,如果某一电子现金账户的审计迹超过了能够存储的限度,则c卡的安全功能应在下次交易时提醒交易存储已满,可选择导出审计迹,并清空审计迹存储空间;或选择按时间顺序覆盖处理,不拒绝交易 8.2.3.3.2支付终端 FAUSTG.3.1如果审计迹超过【赋值:预定的限度】,支付终端安全功能应采取【赋值审计存储可能失效时所采取的行为1. 示例:当支付终端的审计迹超过预定的额度,所采取的行为的例子是采取有效的报警措施,提示操作员导出审计迹,并清空审计迹存储空间 8.2.3.3.3 支付安全前置 FAUSTG.3.1如果审计迹超过【赋值:预定的限度】,支付安全前置安全功能应采取【赋值:审计存航可能失效时哑采服的行丛1. 示例;当支付安全前置的审计迹超过预定的额度,审计迹超过预定的额度的例子是;存储空间,记录条目数,记录时间段;所采取的行为的例子是;自动将审计备份至专用备份设备、采取有效的报警措施提示操作员导出审计迹 8.2.3.3.4支付平台 FAU_STG.3.1如果审计迹超过【赋值;预定的限度】,支付平台安全功能应采取【赋值:让在储可能失效时所采取的行为】. 示例当支付平台审计迹超过赋值的预定的限度时,支付平台应采取有效的报警措施,并通过采用备份后清除等手段,使得审计迹保持在预定的限度之下 8.2.3.4防止审计数据丢失FAU_STG.4) 8.2.3.4.1 支付终端 FAU_STG.4.1如果审计迹已满,支付终端安全功能应【选择,选取一个;“忽略可审计事件”,“阻止们和L赋值市让在鲑可可审计事件，除非具直特权的授权用户产生",“涵盖所存储的最早的审记录" 能失效时所采取的其他动作】注，支付终蹦的安全功能在选择动作时,首先要考虑确保电子支付的安全和可审计示例:对于支付终端,审计存储可能失效时所采用的其他动作是终止服务,并采取有效的报警措施对操作员进行提示 8.2.3.4.2支付安全前置 FAU_STG.4.1如果审计迹已满,支付安全前置安全功能应【选择,选取一个;“忽瞥可审计事件” 25

GB/T31502-2015信息安全技术电子支付系统安全保护框架

随着电子商务和移动支付的不断发展，以及支付行业的逐步开放与竞争，各类电子支付应用层出不穷。在这一背景下，如何保障电子支付系统的安全成为了支付机构、用户和监管机构关注的焦点。而GB/T31502-2015标准正是针对电子支付系统的安全保护提供了标准化的技术要求和指导建议。

1. 标准概述

GB/T31502-2015标准是中国国家标准化管理委员会发布的一项关于电子支付系统安全保护的标准，该标准旨在为电子支付业者提供统一的安全管理框架和技术规范，以确保电子支付系统的信息安全性、可靠性和可用性。

2. 标准内容

GB/T31502-2015标准主要包括以下内容：

术语和定义：明确了标准中所涉及的各类术语和定义，为标准的理解和实施提供了基础。
安全目标和需求：界定了电子支付系统的安全目标和需求，如机密性、完整性和可用性等，为支付机构制定安全策略提供了指导。
安全管理体系：明确了电子支付系统安全管理的基本要素和组成部分，如安全政策、安全组织、风险评估和安全培训等，为建立健全的安全管理体系提供了指导。
安全技术措施：详细介绍了电子支付系统的各种安全技术措施，如身份认证、访问控制、数据保护和安全监测等，为支付机构实施安全措施提供了具体指导。
安全事件管理：规定了电子支付系统安全事件的处理流程和责任分工，为支付机构应对安全事件提供了操作流程参考。

3. 标准意义

GB/T31502-2015标准的发布，旨在为电子支付系统的安全保护提供一个标准化的框架，使得不同的支付机构都能够遵循相同的安全要求和规范，建立起一套完整的安全管理体系和技术措施，从而确保电子支付系统的安全性、可靠性和可用性。此外，该标准还为监管机构提供了一个评估电子支付系统安全性的指标体系，为监管部门制定行业标准和政策提供了参考。

总的来说，GB/T31502-2015标准的发布对于推动电子支付行业的健康发展，保障用户权益，维护市场秩序具有重要意义。

4. 标准实施

根据GB/T31502-2015标准，支付机构应建立完整的电子支付安全管理体系和技术措施，并通过第三方审计机构进行安全审核和认证。同时，支付机构还需严格执行安全事件处理流程，及时处置安全事件，保障用户资产安全。

监管机构也需要加强对电子支付机构的监管和管理，加大对支付机构的安全检查力度，推动行业标准化和规范化发展，确保电子支付市场的健康稳定运营。

5. 结论

GB/T31502-2015标准的发布，为电子支付行业的安全保护提供了标准化的框架和技术要求，使得支付机构能够建立起一套完整的安全管理体系和技术措施，从而有效保障了电子支付系统的信息安全性、可靠性和可用性。在未来，我们相信，该标准还将进一步推动电子支付行业的规范化和健康发展。