GB/T ××××—××××
规划设计实施运行维护废弃确定系统使命确定安全需求安装/开启安全控制安全运行和管理确定系统使命终结将安全需求纳入规格说明安全测试（包括认证）运作保证（监督/审计）审批获得系统（构建/购买）和相关安全活动审批管理更改
图4信息系统生命周期各阶段的安全活动
6.2 规划阶段的风险评估
规划阶段风险评估的目的是识别系统的使命，以支撑系统安全需求及安全战略等。规划阶段的评估应能够描述信息系统建成后对现有业务模式的作用，包括技术、管理等方面，并根据其作用确定系统建设应达到的安全目标。
本阶段评估中，资产、脆弱性不需要识别；威胁应根据未来系统的应用对象、应用环境、业务状况、操作要求等方面进行分析。评估着重在以下几方面：
(1) 是否依据相关规则，建立了与业务战略相一致的信息系统安全规划，并得到最高管理者的认
可；
(2) 系统规划中是否明确信息系统开发的组织、业务变更的管理、开发优先级； (3) 系统规划中是否考虑信息系统的威胁、环境，并制定总体的安全方针；
(4) 系统规划中是否描述信息系统预期使用的信息，包括预期的应用、信息资产的重要性、潜在
的价值、可能的使用限制、对业务的支持程度等；
(5) 系统规划中是否描述所有与信息系统安全相关的运行环境，包括物理和人员的安全配置，以
及明确相关的法规、组织安全策略、习惯、专门技术和知识等。 规划阶段的评估结果应体现在信息系统整体规划或项目建议书中。 6.3 设计阶段的风险评估
设计阶段的风险评估需要根据规划阶段所明确的系统运行环境、资产重要性，提出安全功能需求。设计阶段的风险评估结果应对设计方案中所提供的安全功能符合性进行判断，作为采购过程风险控制的
22
GB/T ××××—××××
依据。
本阶段评估中，应详细评估设计方案中对系统面临威胁的描述，将使用的具体设备、软件等资产列表，以及这些资产的安全功能需求。对设计方案的评估着重在以下几方面：
(1) 设计方案是否符合系统建设规划，并得到最高管理者的认可；
(2) 设计方案是否对系统建设后面临的威胁进行了分析，重点分析来自物理环境和自然的威胁，
以及由于内、外部入侵等造成的威胁；
(3) 设计方案中的安全需求是否符合规划阶段的安全目标，并基于威胁的分析，制定信息系统的总
体安全策略；
(4) 设计方案是否采取了一定的手段来应对系统可能的故障；
(5) 设计方案是否对设计原型中的技术实现以及人员、组织管理等方面的脆弱性进行评估，包括设
计过程中的管理脆弱性和技术平台固有的脆弱性。 (6) 设计方案是否考虑可能随着其他系统接入而产生的风险；
(7) 系统性能是否满足用户需求，并考虑到峰值的影响，是否在技术上考虑了满足系统性能要求的
方法；
(8) 应用系统（含数据库）是否根据业务需要进行了安全设计；
(9) 设计方案是否根据开发的规模、时间及系统的特点选择开发方法，并根据设计开发计划及用户
需求，对系统涉及的软件、硬件与网络进行分析和选型；
(10) 设计活动中所采用的安全控制措施、安全技术保障手段对风险的影响。在安全需求变更和设计
变更后，也需要重复这项评估。
设计阶段的评估可以以安全建设方案评审的方式进行，判定方案所提供的安全功能与信息技术安全技术标准的符合性。评估结果应体现在信息系统需求分析报告或建设实施方案中。 6.4 实施阶段的风险评估
实施阶段风险评估的目的是根据系统安全需求和运行环境对系统开发、实施过程进行风险识别，并对系统建成后的安全功能进行验证。根据设计阶段分析的威胁和制定的安全措施，在实施及验收时进行质量控制。
基于设计阶段的资产列表、安全措施，实施阶段应对规划阶段的安全威胁进行进一步细分，同时评估安全措施的实现程度，从而确定安全措施能否抵御现有威胁、脆弱性的影响。实施阶段风险评估主要对系统的开发与技术/产品获取、系统交付实施两个过程进行评估，
开发与技术/产品获取过程的评估要点包括：
23
GB/T ××××—××××
(1) 法律、政策、适用标准和指导方针：直接或间接影响信息系统安全需求的特定法律；影响信息
系统安全需求、产品选择的政府政策、国际或国家标准； (2) 信息系统的功能需要：安全需求是否有效地支持系统的功能；
(3) 成本效益风险 ：是否根据信息系统的资产、威胁和脆弱性的分析结果，确定在符合相关法律、
政策、标准和功能需要的前提下选择最合适的安全措施。
(4) 评估保证级别：是否明确系统建设后应进行怎样的测试和检查，从而确定是否满足项目建设、
实施规范的要求。
系统交付实施过程的评估要点包括：
(1) 根据实际建设的系统，详细分析资产、面临的威胁和脆弱性；
(2) 根据系统建设目标和安全需求，对系统的安全功能进行验收测试；评价安全措施能否抵御安全
威胁；
(3) 评估是否建立了与整体安全策略一致的组织管理制度；
(4) 对系统实现的风险控制效果与预期设计的符合性进行判断，如存在较大的不符合，应重新
进行信息系统安全策略的设计与调整。
本阶段风险评估可以采取对照实施方案和标准要求的方式，对实际建设结果进行测试、分析。
6.5 运行维护阶段的风险评估
运行维护阶段风险评估的目的是了解和控制运行过程中的安全风险，是一种较为全面的风险评估。评估内容包括对真实运行的信息系统、资产、威胁、脆弱性等各方面。
(1) 资产评估：在真实环境下较为细致的评估，包括实施阶段采购的软硬件资产、系统运行过程中
生成的信息资产、相关的人员与服务等，本阶段资产识别是前期资产识别的补充与增加； (2) 威胁评估：应全面地分析威胁的可能性和影响程度。对非故意威胁导致安全事件的评估可以参
照安全事件的发生频率；对故意威胁导致安全事件的评估主要就威胁的各个影响因素做出专业判断；
(3) 脆弱性评估：是全面的脆弱性评估。包括运行环境中物理、网络、系统、应用、安全保障设备、
管理等各方面的脆弱性。技术脆弱性评估可以采取核查、扫描、案例验证、渗透性测试的方式实施；安全保障设备的脆弱性评估，应考虑安全功能的实现情况和安全保障设备本身的脆弱性；管理脆弱性评估可以采取文档、记录核查等方式进行验证；
(4) 风险计算：根据本标准的相关方法，对重要资产的风险进行定性或定量的风险分析，描述不同
资产的风险高低状况。
24
GB/T ××××—××××
运行维护阶段的风险评估应定期执行；当组织的业务流程、系统状况发生重大变更时，也应进行风
险评估。重大变更包括以下情况（但不限于）：
(1) 增加新的应用或应用发生较大变更； (2) 网络结构和连接状况发生较大变更； (3) 技术平台大规模的更新； (4) 系统扩容或改造；
(5) 发生重大安全事件后，或基于某些运行记录怀疑将发生重大安全事件； (6) 组织结构发生重大变动对系统产生了影响。 6.6 废弃阶段的风险评估
当信息系统不能满足现有要求时，信息系统进入废弃阶段。根据废弃的程度，又分为部分废弃和全部废弃两种。
废弃阶段风险评估着重在以下几方面：
(1) 确保硬件和软件等资产及残留信息得到了适当的处置，并确保系统组件被合理地丢弃或更换； (2) 如果被废弃的系统是某个系统的一部分，或与其他系统存在物理或逻辑上的连接，还应考虑系
统废弃后与其他系统的连接是否被关闭；
(3) 如果在系统变更中废弃，除对废弃部分外，还应对变更的部分进行评估，以确定是否会增加风
险或引入新的风险；
(4) 是否建立了流程，确保更新过程在一个安全、系统化的状态下完成。
本阶段应重点对废弃资产对组织的影响进行分析，并根据不同的影响制定不同的处理方式。对由于系统废弃可能带来的新的威胁进行分析，并改进新系统或管理模式。对废弃资产的处理过程应在有效的监督之下实施，同时对废弃的执行人员进行安全教育。
信息系统的维护技术人员和管理人员均应该参与此阶段的评估。 7 风险评估的工作形式
根据评估发起者的不同，可以将风险评估的工作形式分为自评估和检查评估两类。自评估是由组织自身发起的，以发现系统现有弱点，实施安全管理为目的；检查评估是被评估组织的上级主管机关或业务主管机关发起，通过行政手段加强信息安全的重要措施。
风险评估应以自评估为主，检查评估对自评估过程记录与评估结果的基础上，验证和确认系统存在的技术、管理和运行风险，以及用户实施自评估后采取风险控制措施取得的效果。自评估和检查评估相
25
GB/T ××××—××××
互结合、互为补充。
自评估和检查评估可依托自身技术力量进行，也可委托具有相应资质的风险评估服务技术支持方实施。风险评估服务技术支持方是指具有风险评估的专业人才，对外提供风险评估服务的机构、组织或团体。 7.1 自评估
自评估适用于对自身的信息系统进行安全风险的识别、评价，从而进一步选择合适的控制措施，降低被评估信息系统的安全风险。定期的风险自评估要求可以纳入整个组织安全管理体系中。
自评估应在本标准的指导下，结合系统特定的安全要求进行实施。本标准中的资产赋值、威胁、脆弱性赋值的依据可以根据被评估系统在机密性、完整性、可用性三方面的不同要求程度进行相应的调整，以确定适用于本组织的赋值依据和风险判断依据。周期性进行的自评估可以在评估流程上适当简化，重点考察自上次评估后系统发生变化后引入的新威胁，以及系统脆弱性的完整识别，以便于两次评估结果的对比。但系统发生本标准6.5节中所列的重大变更时，应依据本标准进行完整的评估。
自评估可由发起方实施或委托风险评估服务技术支持方实施。由发起方实施的评估可以降低实施的费用、提高强信息系统相关人员的安全意识，但可能由于缺乏风险评估的专业技能，其缺结果不够深入准确；同时，受到组织内部各种因素的影响，结果缺乏一定的客观性。委托风险评估服务技术支持方实施的评估，过程比较规范、评估结果的客观性比较好，可信程度较高；但由于受到行业知识技能及业务了解的限制，对被评估系统的了解，尤其是在业务方面的特殊要求存在一定的局限。但由于引入第三方本身就是一个风险因素，因此，对其背景与资质、评估过程与结果的保密要求协商等方面应进行控制。
此外，为保证风险评估的实施，与系统相连的相关方也应配合，以防止给其他方的使用带来困难或引入新的风险。 7.2 检查评估
检查评估的实施可以多样化，既可以依据本标准的要求，实施完整的风险评估过程，也可以在对自评估的实施过程、风险计算方法、评估结果等重要环节的科学合理性进行分析的基础上，对关键环节或重点内容实施抽样评估。
检查评估应覆盖以下内容（但不限于）： (1) 自评估方法的检查； (2) 自评估过程记录检查； (3) 自评估结果跟踪检查； (4) 现有安全措施的检查；
26