DB3212_T 1117-2022政务数据安全风险评估规范.pdf

DB3212泰州市地方标准DB3212/T 11172022政务数据安全风险评估规范Government Data Security Risk Assessment Specification2022-12-28 发布2022-12-28 实施ICS 35.020CCS L 70泰 州 市 市 场 监 督 管 理 局发 布DB3212/T 11172022I前言本文件按照 GB/T 1.12020标准化工作导则第 1 部分：标准化文件的结构和起草规则的规定起草。本文件由泰州市大数据管理局提出。本文件由泰州市大数据管理局归口。本文件起草单位：泰州市大数据管理局、泰州市标准化院。本文件主要起草人：陈书剑、王小冬、孙慧、刘小芳、赵文涛、梁鑫晨、许鑫、施驰乐、吴薇、陈蓝生、张婧娴、李海鹏、郭健、王友成。DB3212/T 111720221政务数据安全风险评估规范1范围本文件提供了政务数据安全风险评估的评估原则、风险评估框架及流程、风险评估实施等要求。本文件适用于政务数据安全的风险评估。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 20984信息安全技术 信息安全风险评估方法GB/T 25069信息安全技术 术语GB/T 37973信息安全技术 大数据安全管理指南DB32/T 3421基础地理信息安全系统安全风险评估规范3术语和定义下列术语和定义适用于本文件。3.1政务数据 government data各级政务部门在履行职责过程中依法采集、生成、存储、管理的各类数据资源。注：根据可传播范围，政务数据一般包括可共享政务数据、可开放公共数据及不宜开放共享政务数据。3.2数据安全 data security指通过采取必要措施，确保数据处于有效保护和合法利用的状态，以及具备保障持续安全状态的能力。3.3风险评估 risk assessment风险识别、风险分析和风险评价的整个过程。3.4数据安全风险评估 data security risk assessment是指从风险管理角度，运用科学的方法与手段，根据数据分类分级情况，系统分析数据所面临的安全威胁，以及可能遭受的危害程度，有针对性地提出抵御数据安全威胁的防护对策和措施。3.5安全威胁 security Threat可能对系统或组织的数据处理活动造成危害的因素，其形式可以是对数据直接或间接的攻击，在数据机密性、完整性和可用性等方面造成损害，也可能是偶发的或蓄意的事件。3.6安全脆弱性 security vulnerability通过利用数据安全威胁，导致数据在处理活动中的安全属性被破坏的薄弱环节。4风险评估原则政务数据安全风险评估的基本原则包括：DB3212/T 111720222a)安全保障性原则。不应因风险评估造成基础地理信息数据的泄露、篡改和删除，保障数据的安全性；b)人员可控性原则。所有参与评估人员应签署保密协议，以保证项目信息的安全；c)信息可控性原则。评估方应对工作过程数据和结果数据严格管理，未经授权不得泄露给任何单位和个人；d)过程可控性原则。按照项目管理要求，成立风险评估项目实施团队，并实行项目组长负责制，达到项目过程的可控；e)工具可控性原则。评估人员所使用的评估工具应事先告知用户，并在评估实施前获得被评估方的许可。5风险评估框架及流程5.1风险要素关系风险评估中基本要素的关系如图 1 所示。风险评估基本要素包括资产、威胁、脆弱性和安全措施,并基于以上要素开展风险评估。图 1 风险评估基本要素之间关系5.2风险分析原理风险分析原理如下：a)根据威胁的来源、种类、动机等，并结合威胁相关安全事件、日志等历史数据统计，确定威胁的能力和频率；b)根据脆弱性访问路径、触发要求等，以及已实施的安全措施及其有效性确定脆弱性被利用难易程度；c)确定脆弱性被威胁利用导致安全事件发生后对资产所造成的影响程度；d)根据威胁的能力和频率,结合脆弱性被利用难易程度，确定安全事件发生的可能性；e)根据资产在发展规划中所处的地位和资产的属性，确定资产价值；f)根据影响程度和资产价值，确定安全事件发生后对评估对象造成的损失；g)根据安全事件发生的可能性以及安全事件造成的损失，确定评估对象的风险值；h)依据风险评价准则,确定风险等级，用于风险决策。5.3风险评估流程风险评估的实施流程如图 2 所示。风险评估流程应包括如下内容。DB3212/T 111720223图 2 风险评估实施流程图a)评估准备，此阶段应包括：1)确定风险评估的目标；2)确定风险评估的对象、范围和边界；3)组建评估团队；4)开展前期调研；5)确定评估依据；6)建立风险评价准则；7)制定评估方案。b)评估实施，此阶段应包括：1)政务数据分类；2）政务数据分级；3）政务数据安全威胁识别；4）政务数据脆弱性识别；5）政务数据安全措施确认。c)风险分析与评价，此阶段应包括：1)风险分析计算；2)风险评估；3)风险接受程度；4)风险处置措施。d)编制报告。此阶段应包括处理的重要数据的种类、数量，开展数据处理活动情况，面临数据安全风险及其对应措施等。6风险评估实施DB3212/T 1117202246.1评估准备组织实施风险评估是一种战略性的考虑，其结果将受到组织规划、业务、业务流程、安全需求、系统规模和结构等方面的影响。因此，在风险评估实施前应准备以下工作。a)在考虑风险评估的工作形式、在生命周期中所处阶段和被评估单位的安全评估需求的基础上，确定风险评估目标。附录 A 给出了评估对象生命周期各阶段的风险评估内容，附录 B 给出了风险评估的工作形式描述。b)确定风险评估的对象、范围和边界。c)组建评估团队、明确评估工具。附录 C 给出了风险评估的工具。d)开展前期调研。e)确定评估依据。f)建立风险评价准则：组织应在考虑国家法律法规要求及行业背景和特点的基础上，建立风险评价准则，以实现对风险的控制与管理。风险评价准则应满足以下要求：1）符合组织的安全策略或安全需求；2）满足利益相关方的期望；3）符合组织业务价值。建立风险评价准则的目的包括但不限于：1）对风险评估的结果进行等级化处理；2）能实现对不同风险的直观比较；3）能确定组织后期的风险控制策略。g）制定评估方案。h）评估方案需得到主管单位的支持和批准。6.2评估实施6.2.1数据分类6.2.1.1根据组织的政务数据安全需求以及相关法律法规的规定，按照组织政务数据安全管理的目标和原则，组织定期梳理重要政务数据处理活动有关情况，形成重要政务数据目录。6.2.1.2根据政务数据在经济社会发展中的重要程度，以及遭到篡改、破坏、泄露或者非法获取、非法利用，对国家安全、公共利益或者个人、组织合法权益造成的危害程度，对政务数据实行分类保护。6.2.1.3可参照各地区、各部门以及相关行业、领域按照分保分灰保护制度确定的重要政务数据具体目录。6.2.2数据识别6.2.2.1识别内容系统资产识别包括资产分类和业务承载性识别两个方面。表 1 给出了系统资产识别的主要内容描述。系统资产分类包括信息系统、数据资源和通信网络，业务承载性包括承载类别和关联程度。DB3212/T 111720225表 1系统资产识别表识别内容示例分类信息系统：信息系统是指由计算机硬件、计算机软件、网络和通信设备等组成的，并按照一定的应用目标和规则进行信息处理或过程控制的系统。典型的信息系统如门户网站、业务系统、云计算平台、工业控制系统等数据资源：数据是指任何以电子或者非电子形式对信息的记录。数据资源是指具有或预期具有价值的数据集。在进行数据资源风险评估时，应将数据活动及其关联的数据平台进行整体评估。数据活动包括数据采集、数据传输、数据存储、数据处理、数据交换、数据销毁等通信网络：通信网络是指以数据通信为目的，按照特定的规则和策略，将数据处理结点、网络设备设施互连起来的一种网络。将通信网络作为独立评估对象时，一般是指电信网、广播电视传输网和行业或单位的专用通信网等以承载通信为目的的网络业务承载性承载类别：系统资产承载业务信息采集、传输、存储、处理、交换、销毁过程中的一个或多个环节关联程度：业务关联程度（如果资产遭受损害，将会对承载业务环节运行造成的影响，并综合考虑可替代性）、资产关联程度（如果资产遭受损害，将会对其他资产造成的影响，并综合考虑可替代性）6.2.2.2价值赋值系统资产价值应依据资产的保密性、完整性和可用性赋值，结合业务承载性、业务重要性，进行综合计算，并设定相应的评级方法进行价值等级划分，等级越高表示资产越重要。表 2 中给出了系统资产价值等级划分的描述。资产保密性、完整性、可用性赋值以及业务承载性赋值方法见附录 D。表 2系统资产价值等级表等级标识系统资产价值等级描述5很高综合评价等级为很高，安全属性破坏后对组织造成非常严重的损失4高综合评价等级为高，安全属性破坏后对组织造成比较严重的损失3中等综合评价等级为中，安全属性破坏后对组织造成中等程度的损失2低综合评价等级为低，安全属性破坏后对组织造成较低的损失1很低综合评价等级为很低，安全属性破坏后对组织造成很小的损失，甚至忽略不计6.2.2.3组件和单元资产识别系统组件和单元资产应分类识别，系统组件和单元资产分类包括系统组件、系统单元、人力资源和其他资产。表 3 给出了系统组件和单元资产识别的主要内容描述。DB3212/T 111720226表 3系统组件和单元资产识别表分类示例系统单元计算机设备:大型机、小型机、服务器、工作站、台式计算机、便携计算机等存储设备:磁带机、磁盘阵列、磁带、光盘、软盘、移动硬盘等智能终端设备:感知节点设备（物联网感知终端）、移动终端等网络设备:路由器、网关、交换机等传输线路:光纤、双绞线等安全设备:防火墙、入侵检测/防护系统、防病毒网关、VPN 等系统组件应用系统:用于提供某种业务服务的应用软件集合应用软件:办公软件、各类工具软件、移动应用软件等系统软件:操作系统、数据库管理系统、中间件、开发系统、语句包等支撑平台：支撑系统运行的基础设施平台，如云计算平台、大数据平台等服务接口：系统对外提供服务以及系统之间的信息共享边界，如云计算 PassS 层服务向其他信息系统提供的服务接口等人力资源运维人员：对基础设施、平台、支撑系统、信息系统或数据进行运维的网络管理员、系统管理员等业务操作人员：对业务系统进行操作的业务人员或管理员等安全管理人员：安全管理员、安全管理领导小组等外包服务人员：外包运维人员、外包安全服务或其他外包服务人员等其他资产保存在信息媒介上的各种数据资料:源代码、数据库数据、系统文档、运行管理规程、计划、报告、用户手册、各类纸质的文档等办公设备:打印机、复印机、扫描仪、传真机等保障设备:UPS、变电设备、空调、保险柜、文件柜、门禁、消防设施等服务:为了支撑业务、信息系统运行、信息系统安全,釆购的服务等知识产权:版权、专利等6.2.2.4组件和单元资产赋值系统组件和单元资产价值应依据其保密性、完整性、可用性赋值进行综合计算，并设定相应的评级方法进行价值等级划分,等级越高表示资产越重要。表 4 中给出了系组件和单元资产价值等级划分的描述。资产保密性、完整性、可用性赋值方法见附录 D。表 4系统组件和单元资产价值等级表等级标识系统组件和单元资产价值等级描述5很高综合评价等级为很高，安全属性破坏后对业务和系统资产造成非常严重的影响4高综合评价等级为高,安全属性破坏后对业务和系统资产造成比较严重的影响3中等综合评价等级为中,安全属性破坏后对业务和系统资产造成中等程度的影响2低综合评价等级为低，安全属性破坏后对业务和系统资产造成较低的影响1很低综合评价等级为很低，安全属性破坏后对业务和系统资产造成很小的影响,甚至忽略不计DB3212/T 1117202276.2.3政务数据分级6.2.3.1政务数据分级按照表 5 政务数据分级判定标准可分为 L1、L2、L3、L4 四级，并根据就高性原则进行定级，报部门主要负责人审批同意。表 5政务数据分级判定标准判定等级判定标识判定标准L4涉密数据涉及国家安全、国民经济、民生大事、军事机密等方面的数据；数据被破坏后，会对社会秩序和公共利益造成严重损害，或对国家安全造成损害。L3敏感数据涉及个人或组织人身财产安全、公共利益、社会秩序等方面的数据；数据被破坏后，对公民、法人和其他组织的合法权益造成严重损害，或对社会秩序和公共利益造成损害，但不损害国家安全。L2受限数据涉及个人或组织的基本信息、基本活动信息，可小范围内公开或有条件开放共享的数据；数据被破坏后，对公民、法人和其他组织的合法权益造成一般损害，但不损害国家安全、社会秩序和公共利益。L1公开数据依法公开披露的数据；数据被破坏后，对社会秩序、公共利益以及对公民、法人和其它组织的合法权益均无影响。6.2.4安全威胁识别6.2.4.1威胁识别的内容包括威胁的来源、主体、种类、动机、时机和频率。6.2.4.2在对威胁进行分类前，应识别威胁的来源。威胁来源包括环境、意外和人为三类，附录 D 给出了威胁识别的参考方法。表 6 给出了一种威胁来源的分类方法。6.2.4.3根据威胁来源的不同，威胁可划分为信息损害和未授权行为等威胁种类。表 6 给出了一种威胁种类划分的参考。表 6一种数据安全威胁分类方法数据生命周期阶段数据威胁分类数据威胁描述数据采集恶意代码注入数据入库时，恶意代码随数据注入到数据库或信息系统，危害数据机密性、完整性、可用性。数据无效写入数据入库时，数据不符合规范或无效。数据污染数据入库时，攻击者接入釆集系统污染待写入的原始数据，破坏数据完整性。数据分类分级或标记错误数据分类分级判断错误或打标记错误，导致数据受保护级别降低。数据源不在目前的管理目录或者数据接口管理目录中，造成采集过期数据源或非法数据源。频度不能否满足数据共享的要求，数据产生部门汇集数据与大数据管理平台采集数据频度不一致。数据范围需求小于最初的数据共享范围，共享内容不合规。数据传输数据窃取攻击者伪装成外部通信代理、通信对端、通信链路网关，通过伪造虚假请求或重定向窃取数据。数据监听有权限的员工、第三方运维与服务人员接入，或攻击者越权接入内部通信链路与网关、通信代理监听数据。攻击者接入外部通信链路与网关、通信代理、通信对端监听数据。数据篡改攻击者伪装成通信代理或通信对端篡改数据。数据存储数据破坏由于信息系统自身故障、物理环境变化或自然灾害导致的数据破坏，影响数据完整性和可用性。数据篡改篡改网络配置信息、系统配置信息、安全配置信息、用户身份信息或业务数据信息等，破坏数据完整性和可用性。数据分类分级或标记错误数据分类分级或相关标记被篡改，导致数据受保护级别降低。数据窃取在数据库服务器、文件服务器、办公终端等对象上安装恶意工具窃取数据。恶意代码执行故意在数据库服务器、文件服务器、办公终端等对象上安装恶意工具窃取数据。DB3212/T 111720228数据不可控依托第三方云平台、数据中心等存储数据，没有有效的约束与控制手段。在使用云计算或其他技术时，数据存放位置不可控，导致数据存储在境外数据中心，数据和业务的 司法管辖关系发生改变。数据共享共享数据未脱敏与第三方机构共享数据时，第三方机构及其人员可以直接获取敏感元数据的调取、查看权限。共享权限混乱与第三方机构共享数据时，接口权限混乱，导致第三方能访问其他未开放的数据。数据过度获取由于业务对数据需求不明确，或未实现基于业务人员与所需要数据的关系的访问控制，业务人员 获取超过业务所需的数据，容易造成数据泄露。数据不可控数据可被内部员工获取，组织对内部员工所获数据的保存、处理、再转移等活动不可控。数据可被第三方服务商、合作商获取，组织对第三方机构及其员工所获薮据的使用、留存、再转移等活动未约束或不掌握，数据加工注入攻击数据处理系统可能遭到恶意代码注入、SQL 注入等攻击，造成信息泄露，危害数据机密性、完整性、可用性。数据访问抵赖人员访问数据后，不承认在某时刻用某账号访问过数据。使用权限混乱处理系统调用数据接口权限混乱，导致能访问其他未开放的数据。数据过度获取由于相关业务对数据需求不明确，或未实现基于业务人员、系统与所需数据的关系的访问控制，导致业务人员或处理系统获取超过业务所需数据，容易造成数据泄露。数据不可控依托第三方机构或外部处理系统处理数据，没有有效的约束与控制手段。敏感源数据未脱敏处理系统可直接调取钺感元数据，容易导致信息泄露。数据销毁数据到期未销毁数据失效或业务关闭后，遗留的敏感数据仍然可以被访问，破坏了数据的机密性。数据未正确销毁被销毁数据通过技术手段可恢复，破坏了数据的机密性。6.2.4.4威胁主体依据人为和环境进行区分，人为的分为国家、组织团体和个人，环境的分为一般的自然灾害、较为严重的自然灾害和严重的自然灾害。6.2.4.5威胁动机是指引导、激发人为威胁进行某种活动，对组织业务、资产产生影响的内部动力和原因。威胁动机可划分为恶意和非恶意，恶意包括攻击、破坏、窃取等，非恶意包括误操作、好奇心等。表 E.3 给出了一种威胁动机分类的参考。6.2.4.6威胁时机可划分为普通时期、特殊时期和自然规律。6.2.4.7威胁频率应根据经验和有关的统计数据来进行判断，综合考虑以下四个方面，形成特定评估环境中各种威胁出现的频率：a）以往安全事件报告中出现过的威胁及其频率统计；b）实际环境中通过检测工具以及各种日志发现的威胁及其频率统计；c）实际环境中监测发现的威胁及其频率统计；d）近期公开发布的社会或特定行业威胁及其频率统计，以及发布的威胁预警。6.2.4.8威胁赋值威胁赋值应基于威胁行为，依据威胁的行为能力和频率，结合威胁发生的时机，进行综合计算，并设定相应的评级方法进行等级划分，等级越高表示威胁利用脆弱性的可能性越大。表 7 中给出了威胁赋值等级划分的描述。DB3212/T 111720229表 7种基于发生频率的数据安全威胁赋值方法数据安全威胁频率威胁赋值数据安全威胁频率定义很高5在该行业领域的业务系统中，通常不可避免的威胁，发生频率很高（或 N1 次/周）；或可以证实经常发生过。高4在该行业领域的业务系统中，在多数情况下会发生的威胁，发生频率高（或 N1 次/月）；或可以证实多次发生过。中等3在该行业领域的业务系统中，在特定条件下可能会发生的威胁，发生频率中等（或次/半年）；或被证实曾经发生过。低2在该行业领域的业务系统中，一般不太容易发生的威胁，发生频率低；或没有被证实发生过。很低1在该行业领域的业务系统中，很罕见和例外的情况下会发生的威胁，发生频率很低；或几乎不可能发生。6.2.5安全脆弱性识别6.2.5.1政务数据安全脆弱性识别是依据国际、国家安全标准或者行业规范、应用流程的安全要求，从管理与技术两个角度进行综合识别。当政务数据安全不能满足以下数据安全防护要求时，会产生政务数据安全脆弱性，评估人员应从以下方面进行数据安全脆弱性识别：a)政务数据采集：1）政务部门应根据本部门履行职责的需要依法采集信息，明确采集信息的范围、格式和采集流程，按照相关标准规范要求，在目录管理系统登记数据，确保数据真实、准确、完整和及时。2）各区委应根据自身实际情况，确定数据采集范围、数量和频度，确定采集过程中个人信息和重要数据的采集范围、控制措施。3）政务信息采集应遵循“源头采集、一数一源”的原则，凡可以通过共享获取的信息，各政务部门原则上不得要求自然人、法人或其他组织重复提交，法律、法规另有规定的除外。4）自然人数据应当以居民身份证号码作为标识进行采集，法人及其他组织数据应当以统一社会信用代码作为标识进行采集。5）政务部门应按相关技术标准对采集的政务数据开展数字化和结构化处理。对列入政务信息资源共享目录和开放目录的信息资源，未建设相应业务系统的，政务部门应按照相关技术标准积极开展业务系统建设，确保业务数据库与信息共享平台和数据开放平台之间的互联互通和同步更新。6）在数据抽取过程中使用到的中间账户应是专门为中台系统设计，且遵循“最小够用”原则。7）应记录并保存政务数据处理活动过程相关的信息。8）应对政务数据源和数据采集的环境、设施、技术采取必要的安全机制和管控措施，对产生数据的数据源进行身份鉴别和记录，确保采集数据的机密性、完整性和真实性。b)政务数据传输：1）数据传输过程中的身份鉴别技术应具备安全性，使得数据信息不会被非法操作或越权访问。2）确保数据传输应采用加密通道、元数据加密、去标识化、完整性校验或其他技术保证传输过程中的机密性和完整性，包括但不限于个人信息数据、业务信息数据、鉴别信息数据、日志信息数据等。3）应建立政务数据传输链路冗余机制，保证数据传输的可靠性和网络传输服务可用性。c)政务数据存储：1）政务部门应将政务信息资源统一存储到泰州市政务信息共享开放平台，加强数据存储前的保密审查，原则上机密级以下涉密数据通过全市电子政务内网平台承载，非涉密数据通过政务信息共享开放平台承载。DB3212/T 11172022102）政务数据存储应采用身份鉴别技术对数据访问者身份进行识别，确保数据在授权的安全范围内被使用、访问、操作，防止数据被任意读取，造成数据泄露或数据安全属性被破坏等后果。3）政务数据存储应采用校验技术或密码技术保证重要数据在存储过程中的完整性，包括但不限于个人信息数据、业务信息数据、鉴别信息数据、日志信息数据等。4）应采用密码技术保证重要数据在存储过程中的机密性，包括但不限于业务信息数据、鉴别信息数据、日志信息数据等。5）应规定重要数据的备份方式、备份频度、存储介质、保存期等。6）应根据政务数据的重要性和政务数据对系统运行的影响，制定政务数据的备份和恢复策略、备份和恢复程序等。7）政务部门对政务数据涉密属性不明确或者有争议的，按照保密法有关规定执行。d)政务数据共享：1）涉及个人信息的政务数据开放内容，应根据业务对个人信息进行必要的去标识化处理。2）应能够检测开放数据资源是否含有非公开信息能力，确保公开数据合规。3）应具备对异常或高风险数据访问行为自动化识别和预警的能力，及时阻断违规行为。e)政务数据加工：1）应建立数据加工节点的安全机制，确保节点接入的真实性，防止数据泄露。2）在数据分析过程中对数据获取、访问接口、授权机制进行管控，应建立多源数据派生、聚合、关联分析过程的管控措施，避免分析结果泄露敏感数据、个人信息。3）应建立数据溯源机制，实现数据流向追踪，并对溯源数据进行保护。4）应建立数据加工再利用管控机制，确保对数据加工产生的组谷数据、关联数据、衍生数据的违规使用、未授权滥用、非法转存、跨境存储进行检测评估。f)政务数据销毁：1）应使用规范的工具或产品，采用可靠技术手段及时销毁符合销毁条件的数据，确保数据不可还原。2）对于数据存储介质的销毁，应使用国家权威机构认证的设备或国家认定资质的销毁服务提供商对存储介质设备进行物理销毁。6.2.5.2可根据政务数据的暴露程度、技术实现的难易程度、流行程度等，采用分级方式对数据安全脆弱性指数赋值,见表 8。表 8一种政务数据安全脆弱性指数与赋值方法政务数据安全脆弱性指数指数赋值政务数据安全脆弱性指数程度定义很高5如果政务数据安全脆弱性被利用，会对组织及其拥有的数据造成芫全损害。高4如果政务数据安全脆弱性被利用，会对组织及其拥有的数据造成重大损害。中等3如果政务数据安全脆弱性被利用，会对组织及其拥有的数据造成较大损害。低2如果政务数据安全脆弱性被利用，会对组织及其拥有的数据造成一般损害。很低1如果政务数据安全脆弱性被利用，会对组织及其拥有的数据造成较小损害。6.2.6安全措施确认DB3212/T 11172022116.2.6.1在识别政务数据安全脆弱性的同时，评估人员应对数据安全措施的有效性进行评估确认。对有效的安全措施继续保持，对确认为不适当的安全措施应核实是否应被取消或对其进行修正，或用更合适的安全措施替代。6.2.6.2政务数据安全措施确认结果包括两种情况：a)防护措施对数据安全保障起到加强作用，此类防护措施应加以保持。b)对数据安全保障起到削弱作用，此类防护措施应被调整并予以加强。6.2.6.3政务数据安全措施调节因数。在对数据安全风险进行分析评价时，应考虑数据、数据安全威胁、数据安全脆弱性的综合作用以及数据安全措施产生的加强或削弱作用，因此引入数据安全措施调节因数对数据安全风险进行修正。6.2.6.4政务数据安全措施调节因数的取值应设置在一个合理的取值区间，能够反映现有数据安全措施对数据安全保障产生的加强或削弱作用。6.3风险分析与评价6.3.1应结合数据风险值计算和数据风险面临的风险等级对数据进行定量与定性的综合分析与评价。6.3.2应根据数据安全风险分析与评价过程应确定影响数据安全风险的要素、要素之间的组合方式以及具体的计算方法。影响数据安全风险的要素主要包括数据安全威胁频率、数据安全脆弱性指数、数据级别以及现有数据安全措施。6.3.3应根据安全威胁利用数据的脆弱性造成的破坏对数据安全风险进行评价。6.4编制报告6.4.1同时结合现有数据安全措施对数据安全风险的加强或削弱作用进行关联分析，并编制数据安全风险评估报告。6.4.2被评估组织根据本行业、单位的风险管理策略，确认数据安全风险接受程度，对不可接受的数据安全风险，应釆取风险管控措施进行控制。AADB3212/T 1117202212附录A（资料性）评估对象生命周期各阶段的风险评估A.1概述风险评估应贯穿于评估对象生命周期各阶段中。评估对象生命周期各阶段中涉及的风险评估原则和方法是一致的，但由于各阶段实施内容、对象、安全需求不同，使得风险评估的对象、目的、要求等各方面也有所不同。在规划设计阶段，通过风险评估以确定评估对象的安全目标；在建设验收阶段，通过风险评估以确定评估对象的安全目标达成与否；在运行维护阶段，要持续的实施风险评估以识别评估对象面临的不断变化的风险和脆弱性，从而确定安全措施的有效性，确保安全目标得以实现。因此，每个阶段风险评估的具体实施应根据该阶段的特点有所侧重的进行。A.2规划阶段的风险评估规划阶段风险评估的目的是识别评估对象的业务规划，以支撑评估对象安全需求及安全规划等。规划阶段的评估应能够描述评估对象建成后对现有业务模式的作用，包括技术、管理等方面，并根据其作用确定评估对象建设应达到的安全目标。本阶段评估中，资产、脆弱性不需要识别；威胁应根据未来应用对象、应用环境、业务状况、操作要求等方面进行分析。评估着重在以下几方面：a）是否依据相关规则，建立了与业务规划相一致的安全规划，并得到最高管理者的认可；b）是否依据业务建立与之相契合的安全策略，并得到最高安全管理者的认可；c）系统规划中是否明确评估对象开发的组织、业务变更的管理、开发优先级；d）系统规划中是否考虑评估对象的威胁、环境，并制定总体的安全方针；e）系统规划中是否描述评估对象预期使用的信息，包括预期的信息系统、资产的重要性、潜在的价值、可能的使用限制、对业务的支持程度等；D 系统规划中是否描述所有与评估对象安全相关的运行环境，包括物理和人员的安全配置，以及明确相关的法规、组织安全策略、专门技术和知识等。规划阶段的评估结果应体现在评估对象整体规划或项目建议书中。A.3设计阶段的风险评估设计阶段的风险评估需要根据规划阶段所明确的运行环境、业务重要性、资产重要性，提出安全功能需求设计阶段的风险评估结果应对设计方案中所提供的安全功能符合性进行判断，作为实施过程风险控制的依据。本阶段评估中，应详细评估设计方案中面临威胁的描述，将评估对象使用的具体设备、软件等资产及其安全功能形成需求列表。对设计方案的评估着重在以下几方面：a）设计方案是否符合评估对象建设规划，并得到最高管理者的认可；b）设计方案是否对评估对象建设后面临的威胁进行了分析，重点分析来自物理环境和自然的威胁，以及由于内、外部入侵等造成的威胁；c）设计方案中的安全需求是否符合规划阶段的安全目标，并基于威胁的分析，制定评估对象的总体安全策略；d）设计方案是否采取了一定的手段来应对可能的故障；e）设计方案是否对设计原型中的技术实现以及人员、组织管理等方面的脆弱性进行评估，包括设计过程中的管理脆弱性和技术平台固有的脆弱性；f）设计方案是否考虑随着其他系统接入而可能产生的风险；g）系统性能是否满足用户需求，并考虑到峰值的影响，是否在技术上考虑了满足系统性能要求的方法；h）应用系统（含数据库）是否根据业务需要进行了安全设计；i）设计方案是否根据开发的规模、时间及系统的特点选择开发方法，并根据设计开发计划及用户需求，对系统涉及的软件、硬件与网络进行分析和选型；DB3212/T 1117202213J）设计活动中所釆用的安全控制措施、安全技术保障手段对风险的影响。在安全需求变更和设计变更后，也需要重复这项评估。设计阶段的评估可以以安全建设方案评审的方式进行，判定方案所提供的安全功能与信息技术安全技术标准的符合性。评估结果应体现在评估对象需求分析报告或建设实施方案中。A.4实施阶段的风险评估实施阶段风险评估的目的是根据安全需求和运行环境对系统开发、实施过程进行风险识别，并对建成后的安全功能进行验证。根据设计阶段分析的威胁和制定的安全措施，在实施及验收时进行质量控制。基于设计阶段的资产列表、安全措施，实施阶段应对规划阶段的安全威胁进行进一步细分，同时评估安全措施的实现程度，从而确定安全措施能否抵御现有威胁、脆弱性的影响。实施阶段风险评估主要对业务及其相关信息系统的开发、技术与产品获取，系统交付实施两个过程进行评估。开发、技术与产品获取过程的评估要点包括：a）法律、政策、适用标准和指导方针：直接或间接影响评估对象安全需求的特定法律；影响评估对象安全需求、产品选择的政府政策、国际或国家标准；b）评估对象的功能需要：安全需求是否有效地支持系统的功能；c）成本效益风险：是否根据评估对象的资产、威胁和脆弱性的分析结果，确定在符合相关法律、政策、标准和功能需要的前提下选择最合适的安全措施；d）评估保证级别：是否明确系统建设后应进行怎样的测试和检查，从而确定是否满足项目建设、实施规范的要求。A.5交付阶段的风险评估系统交付实施过程的评估要点包括：a）根据实际建设的系统，详细分析资产、面临的威胁和脆弱性；b）根据系统建设目标和安全需求，对系统的安全功能进行验收测试；评价安全措施能否抵御安全威胁；c）评估是否建立了与整体安全策略一致的组织管理制度；d）对系统实现的风险控制效果与预期设计的符合性进行判断，如存在较大的不符合，应重新进行评估对象安全策略的设计与调整。本阶段风险评估可以采取对照实施方案和标准要求的方式，对实际建设结果进行测试、分析。A.6运行阶段的风险评估运行维护阶段风险评估的目的是了解和控制运行过程中的安全风险，是一种较为全面的风险评估。评估内容包括对真实运行的资产、威胁、脆弱性等各方面。a）资产评估：包括对业务、系统资产、系统组件和单元资产的评估。业务评估包括业务定位、业务关联性、完整性、业务流程分析；系统资产评估包括系统分类和业务承载连续性的评估；系统组件和单元资产是在真实环境下较为细致的评估，包括实施阶段采购的软硬件资产、系统运行过程中生成的信息资产、相关的人员与服务等，本阶段资产识别是前期资产识别的补充与增加。b）威胁评估：应全面地分析威胁的可能性和严重程度。对威胁导致安全事件的评估可以参照威胁来源动机、能力和安全事件的发生频率。c）脆弱性评估：是全面的脆弱性评估。包括运行环境中物理、网络、系统、应用、安全保障设备、管 理等各方面的脆弱性。技术脆弱性评估可以采取核查、扫描、案例验证、渗透性测试的方式实施；安全保障设备的脆弱性评估，应包括安全功能的实现情况和安全保障设备本身的脆弱性；管理脆弱性评估可以采取文档、记录核查等方式进行验证。d）风险计算：根据本文件的相关方法，对风险进行定性或定量的风险分析，描述不同业务、系统资产的风险高低状况。运行维护阶段的风险评估应定期执行；当组织的业务流程、系统状况发生重大变更时，也应进行风险评估，重大变更包括以下情况（但不限于）:a）增加新的应用或应用发生较大变更；b）网络结构和连接状况发生较大变更；c）技术平台大规模的更新；d）系统扩容或改造；DB3212/T 1117202214e）发生重大安全事件后，或基于某些运行记录怀疑将发生重大安全事件；D 组织结构发生重大变动对系统产生了影响。A.7废弃阶段的风险评估废弃阶段风险评估着重在以下几方面：a）确保硬件和软件等资产及残留信息得到了适当的处置，并确保系统组件被合理地丢弃或更换；b）如果被废弃的系统是某个系统的一部分，或与其他系统存在物理或逻辑上的连接，还需考虑系统废弃后与其他系统的连接是否被关闭；c）如果在系统变更中废弃，除对废弃部分外，还应对变更的部分进行评估，以确定是否会增加风险或引入新的风险；d）是否建立了流程，确保更新过程在一个安全、系统化的状态下完成。本阶段应重点对废弃资产对组织的影响进行分析，并根据不同的影响制定不同的处理方式。对由于系统废弃可能带来的新的威胁进行分析，并改进新系统或管理模式。对废弃资产的处理过程应在有效的监督之下实施，同时对废弃的执行人员进行安全教育，评估对象的维护技术人员和管理人员均应参与此阶段的评估。DB3212/T 1117202215B B附录B（资料性）风险评估的工作形式B.1自评估自评估是指评估对象的拥有、运营或使用单位发起的对本单位进行的风险评估。自评估应在本文件的指导下，结合评估对象特定的安全要求实施。周期性进行的自评估可以在评估流程上适当简化，重点针对自上次评估后评估对象发生变化后引入的新威胁，以及脆弱性的完整识别，以便于两次评估结果的对比。但评估对象发生 A.6 中所列的重大变更时，应依据本文件进行完整的评估。自评估可由发起方实施或委托风险评估服务技术支持方实施。由发起方实施的评估可以降低实施的费用、提高相关人员的安全意识，但可能由于缺乏风险评估的专业技能，其结果不够深入准确；同时，受到组织内部各种因素的影响，其评估结果的客观性易受影响。委托风险评估服务技术支持方实施的评估，过程比较规范、评估结果的客观性比较好，可信程度较高；但由于受到行业知识技能及业务了解的限制，对评估对象的了解，尤其是在业务方面的特殊要求存在一定的局限。由于引入风险评估服务技术支持方本身就是一个风险因素，因此，对其背景与资质、评估过程与结果的保密要求等方面应进行控制。此外，为保证风险评估的实施，与评估对象相连的相关方也应配合，以防止给其他方的使用带来困难或引入新的风险。B.2检查评估检查评估是指评估对象上级管理部门组织的或国家有关职能部门开展的风险评估。检查评估可依据本文件的要求，实施完整的风险评估过程。检查评估也可在自评估实施的基础上，对关键环节或重点内容实施抽样评估，包括以下内容（但不限于）:a）自评估队伍及技术人员审查；b）自评估方法的检查；c）自评估过程控制与文档记录检查；d）自评估资产列表审查；e）自评估威胁列表审查；f）自评估脆弱性列表审查；g）现有安全措施有效性检查；h）自评估结果审查与釆取相应措施的跟踪检查；i）自评估技术技能限制未完成项目的检查评估；j）上级关注或要求的关键环节和重点内容的检查评估；k）软硬件维护制度及实施管理的检查；l）突发事件应对措施的检查。检查评估也可委托风险评估服务技术支持方实施，但评估结果仅对检查评估的发起单位负责。由于检查评估代表了主管机关，涉及评估对象也往往较多，因此，要对实施检查评估机构的资质进行严格管理。DB3212/T 1117202216C C附录C（资料性）风险评估的工具C.1概述风险评估工具是风险评估的辅助手段，是保证风险评估结果可信度的一个重要因素。风险评估工具的使用不但在一定程度上解决了手动评估的局限性，最主要的是它能够将专家知识进行集中，使专家的经验知识被广泛地应用。根据在风险评估过程中的主要任务和作用原理的不同，风险评估的工具可以分成风险评估与管理工具、系统基础平台风险评估工具、风险评估辅助工具三类。风险评估与管理工具是一套集成了风险评估各类知识和判据的管理信息系统，以规范风险评估的过程和操作方法；或