DB14∕T 1252-2016 信息化工程安全建设和管理规范

ICS25.04025.040DB14山西省质量技术监督局IDB14/T1252—2016前言 12规范性引用文件 13术语和定义 14信息化工程安全管理概述 24.1信息系统生命周期 24.2信息安全工程过程 44.3信息化工程安全管理制度 54.4信息化工程安全项目管理 55规划安全目标 55.1分析信息安全需求 65.2定义系统安全要求 86设计安全方案 96.1设计安全体系结构 106.2开展详细的安全设计 117实施安全方案 7.1开发和采购 7.2安全集成 7.3验收 8开展安全运维 8.1信息安全风险评估和监测 198.2事件处理和应急响应 208.3灾难备份和业务连续性计划 208.4配置管理 8.5变更管理 8.6维修维护 9确保废弃过程的安全 9.1信息安全风险评估 219.2业务迁移与连续性 219.3介质处理 10监督管理 10.1信息安全监管部门的监督检查 22DB14/T1252—201610.2自身信息化工程安全管理 22附录A（资料性附录）信息化工程安全管理相关政策要求 参考文献 DB14/T1252—2016本标准按照GB/T1.1—2009给出的规则起草。本标准由山西省经济和信息化委员会提出并归口。本标准起草单位：山西省信息技术产业协会、山西省经贸决策咨询中心、中国信息安全研究院有限公司、山西省信息化和信息安全评测中心、山西省工业控制系统与安全产业联盟。本标准主要起草人：周亚超、左晓栋、李凯军、王乐、薛云琴、张明胜、陆希、苑化军、张卓雅、郭陈勋、刘雨桁。DB14/T1252—2016近年来，随着网络信息技术快速发展应用，网络安全形势日趋复杂严峻，对标准化工作提出了更高要求。中央网络安全和信息化领导小组第一次会议指出，网络安全和信息化是一体之两翼、驱动之双轮，必须统一谋划、统一部署、统一推进、统一实施。做好网络安全和信息化工作，要处理好安全和发展的关系，做到协调一致、齐头并进，以安全保发展、以发展促安全，努力建久安之势、成长治之业。《国务院关于大力推进信息化发展和切实保障信息安全的若干意见》（国发〔2012〕23号）要求，重要信息系统和基础信息网络要同步规划、同步建设、同步运行安全防护设施。《山西省信息化促进条例》提出，信息安全系统应当与信息化工程同时设计、同时施工、同时投入使用。为贯彻落实党中央、国务院和山西省有关规定，落实网络强国战略，深化标准化工作改革，构建统一权威、科学高效的信息化工程安全建设管理标准体系和标准化工作机制，加强标准体系建设，科学构建标准体系，推动信息化工程安全建设管理标准与国家相关法律法规的配套衔接，促进信息化工程安全建设管理标准与信息化应用标准同步规划、同步制定，提高标准适用性、先进性和规范性，提升标准信息服务能力和标准符合性测试能力，在信息系统设计和建设过程中，应同步考虑信息安全需求，信息安全贯穿于信息化工程建设的每一个生命周期阶段。为此，制定本标准。1DB14/T1252—2016信息化工程安全建设和管理规范本标准规定了在信息化工程建设的全生命周期过程中有关信息安全的要求。本标准适用于山西省辖区内各级机关、事业单位、重要领域新建和改扩建信息化工程安全建设及管理工作，作为信息安全监督、检查、验收、评估等工作的重要依据。2规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB9387.2—1995信息处理系统开放系统互联基本参考模型第2部分：安全体系结构GB/T18794（所有部分）信息技术开放系统互联开放系统安全框架GB/T19668.6—2007信息化工程监理规范第6部分：信息化工程安全监理规范GB/T20261—2006信息技术系统安全工程能力成熟度模型GB/T20282—2006信息安全技术信息系统安全工程管理要求GB/T20984—2007信息安全技术信息安全风险评估规范GB/Z20985—2007信息技术安全技术信息安全事件管理指南GB/T20988—2007信息安全技术信息系统灾难恢复规范GB/T22032—2008系统工程系统生存周期过程GB/T22081—2008信息技术安全技术信息安全管理实用规则GB/T22239—2008信息安全技术信息系统安全等级保护基本要求GB/T25070—2010信息安全技术信息系统等级保护安全设计技术要求GB/T25069—2010信息安全技术术语GB/T28448—2012信息安全技术信息系统安全等级保护测评要求GB/T28449—2012信息安全技术信息系统安全等级保护测评过程指南GB/T30273—2013信息安全技术信息系统安全保障通用评估指南GB/T30976.1—2014工业控制系统信息安全第1部分：评估规范GB/T30976.2—2014工业控制系统信息安全第2部分：验收规范DB14/T1251—2016信息技术服务外包安全要求3术语和定义GB/T25069—2010确立的以及下列术语和定义适用于本文件。3.1信息系统生命周期2DB14/T1252—2016信息系统从无到有，再到废弃的整个过程，一般分为规划、设计、实施、运维、废弃阶段。每一阶段又可细分为多个步骤，如规划阶段分为分析需求、定义系统等步骤，设计阶段分为体系结构设计、详细设计等步骤，实施阶段分为开发和采购、集成、验收等步骤。3.2信息安全工程为确保信息系统的保密性、完整性、可用性、可追究性、抗否认性等目标而开展的系统性活动的总称。3.3信息安全工程过程在整个信息系统生命周期中，将输入转变为输出的一组信息安全工程[3.2]相关活动，包括规划安全目标、设计安全方案、实施安全方案、开展安全运维、确保废弃过程的安全。3.4信息系统体系结构对信息系统的各组成要素、各组成要素的功能及各要素之间逻辑关系的描述。3.5信息系统安全体系结构对信息系统安全防护体系的各组成要素、各组成要素的功能及各要素之间逻辑关系的描述。3.6信息化工程运用电子信息技术、网络互连技术和现代通讯技术等，开发信息资源，建设信息化系统的工程过程。4信息化工程安全管理概述4.1信息系统生命周期4.1.1概述信息系统生命周期包括5个基本阶段，即规划、设计、实施、运维和废弃1）。在每一个阶段完成时，都需要对该阶段的有效性进行评估。在以上过程中，还需保持与用户的密切沟通，以反映用户需求、接收用户反馈，如下页图1所示。程、实现过程、集成过程、验证过程、移交过程、确认过程、运行过程、维护过3DB14/T1252—2016图1信息系统生命周期展现方框图4.1.2规划规划阶段包括但不限于以下任务：a)分析信息系统的业务需求，并全面梳理与信息系统有关的政策、法规和标准。b)采用自然语言描述信息系统需要具备的功能及性能，包括信息系统的外部接口、外部信息流，并将自然语言翻译为可视化的工程图表，在其中明确定义系统的外部接口及系统边界。功能描述应能够反映系统的预期运行效果，性能描述则用来定义功能的实现程度。功能和性能描述应与需求全面对应，且明确、可测、可验证。c)除规定系统的功能、接口、性能、互操作性外，还应向用户承诺已定义的系统功能中不会存在用户不需要的其他功能。4.1.3设计设计阶段包括但不限于以下任务：a)分析待建系统的体系结构，确定系统中的各类组件或要素，并描述这些组件或要素之间的逻辑关系。b)分析系统的设计约束，特别是环境、资源限制及已明确的政策、法规和标准的强制性要求，在此基础上完成详细的系统设计，形成底层的接口规范、具体的拓扑图等。c)确保将所有的系统功能和性能要求落实到系统组件。4.1.4实施实施阶段包括但不限于以下任务：a)采购现货产品或开发定制化的系统组件，并对各项组件进行测试，判断其是否满足系统设计阶段为该组件分配的功能和性能。b)完成测试后，对各项组件进行系统集成，实现整体性能最优，即所有组件整合在一起后不但能够工作，而且全系统的性价比最高，系统具有充分的可扩充性和可维护性。c)系统集成完毕后，进行线下和线上测试，以验证系统的运行是否满足用户需求、符合预定设计目标。在实施线上测试时，应事先制定应急预案。d)对信息系统进行验收，核查重要的系统文档并妥善保存，包括系统的安装、操作、维护手册，以及前期需求分析、设计和开发文档。4DB14/T1252—20164.1.5运维在运行维护阶段，信息系统运维人员依据各种管理标准、制度和规范，利用运维管理系统和其他运维管理工具，实施事件管理、问题管理、配置管理、变更管理等活动，以保障信息系统平稳、高效运行。4.1.6废弃当信息系统的功能不再需要时，信息系统进入废弃阶段。在废弃阶段，可根据情况完成以下任务，包括但不限于：a)必要时对原有业务进行迁移，确保业务的平滑过渡。b)对数据进行归档和删除，对介质进行清除，防止敏感信息被恢复。c)对软硬件进行废弃处置。4.2信息安全工程过程信息系统的安全体系是信息系统完整不可分割的一部分，在信息系统生命周期的每一阶段均需开展信息安全活动。表1描述了信息安全工程过程与信息系统生命周期阶段的对应关系。表1信息安全工程过程与信息系统生命周期的对应关系分析信息安全需求：分析用户对业务运行时分析需求：从业务角度，分析用户对规划定义系统安全要求：定义信息系统的安全功定义系统：定义信息系统的功能和性设计安全体系结构：设计信息系统的信息安全体系结构，确定系统中的各类安全组件，并明确各类组件的安全机制。此外，还需描设计体系结构：分析待建系统的体系并描述这些组件或要素之间的逻辑关设计开展详细的安全设计：形成信息安全底层接口规范、具体的拓扑图等。所有的信息安全功能和性能要求应落实到具体的信息安全组具体的拓扑图等。所有的系统功能和性能要求应落实到具体的系统组件，开发和采购：开发定制的信息安全组件，采购现货信息安全产品，以实现已确定的信息安全机制。此外，还需确保信息系统开发和实施安全集成：将信息安全组件集成到信息系统验收：验证系统中的安全措施是否满足用户验收：验证系统的运行是否满足用户监测、处置信息安全事件，对信息安全设备进行配置管理，升级安全补丁。确保信息系实施事件管理、配置管理、变更管理运维对软硬件及信息进行处置，实现新旧废弃5DB14/T1252—20164.3信息化工程安全管理制度信息化工程安全管理制度除应符合国家相关法律、法规要求外，还应符合其他有关标准的要求，包括但不限于：—GB/T20261—2006明确了信息安全工程过程的主要任务，提出了信息安全工程能力成熟度模型，规定了信息安全工程的项目组织活动。—GB/T20282—2006明确了信息安全工程实施要求和项目实施要求，提出了分等级的信息安全工程管理要求。—GB/T19668.6—2007提出了信息化工程招标、设计、实施、验收阶段的安全监理规范，并明确了各类信息化工程的安全监理要点。—GB/T22081—2008提出了“信息系统获取、开发和维护”要求。—GB/T22239—2008提出了“系统建设管理”要求。4.4信息化工程安全项目管理4.4.1组织机构应有专人负责信息安全工作或成立信息安全管理机构，并满足以下要求：a)信息安全管理机构应在信息化工程建设之初便参与信息系统生命周期的所有活动，并能够在各阶段的活动中充分表达意见。要以信息安全部门为主成立信息安全工程小组，负责信息化工程中信息安全工程的管理。信息安全部门对信息化工程的重大决策拥有一票否决权。b)应成立内部协调机制，在信息化工程建设过程中处理业务部门、信息化部门与信息安全部门之间可能出现的分歧，提高信息化工程的整体性、协调性。4.4.2管理任务应按照GB/T20282—2006的“组织保证要求”和“项目实施要求”，贯彻工程项目管理的思路，对信息化工程安全项目实施全过程管理，管理任务包括但不限于：a)明确项目范围。b)确定所需资源及其可用性。c)确定相关角色和责任，定义管理接口。d)估算项目成本。e)制定项目进度计划。f)确定项目可交付项。g)制定项目管理规划。h)与用户沟通，获得用户认同。i)建立专家团队，指导技术工作。j)跟踪项目资源。k)跟踪技术参数。l)监督技术活动的进展，报告项目状态。m)确保可交付项的质量。n)开展项目有效性评估，审查项目绩效。5规划安全目标6DB14/T1252—20165.1分析信息安全需求5.1.1主要任务分析信息安全需求是信息化工程安全建设的起点，应从本机构的职能或业务的角度分析对信息安全的需求。与之相关的任务主要有以下几个方面：a)梳理本机构的职能或业务对信息系统的需求。b)分析本机构信息系统面临的威胁。c)结合本机构的职能或业务特性，分析信息安全威胁可能对本机构造成的影响。d)明确本机构职能或业务对信息的保密性、完整性、可用性需求。e)描述本机构信息系统中涉及信息安全的角色和责任。f)梳理法律法规、政策文件对信息安全的强制性要求，以及本机构的上级机构或关联机构对信息安全的约束性规定。g)从信息安全威胁、可能造成的影响等角度，评估信息安全需求的有效性。5.1.2任务输出应编制以下文档：a)威胁分析和后果分析报告。b)相关法律法规、政策文件及其他约束性规定列表。c)信息安全需求说明书，该说明书应得到用户签字认可。5.1.3方法应按照GB/T20984—2007提出的风险评估规范，采用以下方法，对信息系统面临的信息安全威胁和影响进行评估分析，但资产、脆弱性不需要识别：a)威胁评估应根据未来系统的应用对象、应用环境、业务状况、操作要求等方面开展，并着重以下几方面：1)是否依据相关规则，建立了与业务战略相一致的信息系统安全规划，并得到最高管理者的认可。2)系统规划中是否考虑了信息系统的威胁、环境，并制定了总体的安全方针。3)系统规划中是否描述了有关信息系统预期使用方面的信息，包括预期的应用、信息资产的重要性、潜在的价值、可能的使用限制、对业务的支持程度等。4)系统规划中是否描述了所有与信息系统安全相关的运行环境，包括物理和人员的安全配置，以及明确相关的法规、组织安全策略、专门技术和知识等。b)威胁可以通过威胁主体、资源、动机、途径等多种属性来描述。造成威胁的因素可分为人为因素和环境因素。根据威胁的动机，人为因素又可分为恶意和非恶意两种。环境因素包括自然界不可抗的因素和其他物理因素。威胁作用形式可以是对信息系统直接或间接的攻击，在保密性、完整性和可用性等方面造成损害；也可能是偶发的、或蓄意的事件。c)在对威胁进行分类前，应考虑威胁的来源。表2提供了一种威胁来源的分类方法。7DB14/T1252—2016表2威胁来源列表事故等环境危害或自然灾害，以及软件、硬件、数据、通讯d)对威胁进行分类的方式有多种，针对表2的威胁来源，可以根据其表现形式将威胁主要分为不同类型。表3提供了一种基于表现形式的威胁分类方法。表3一种基于表现形式的威胁分类表对业务实施或系统运行产生影响的设备硬件故对信息系统正常运行造成影响的物理环境问题无作为或操作失误非授权访问网络资源、非授权访问系统资利用工具和技术通过网络对信息系统进行攻击8DB14/T1252—2016e)在梳理信息系统面临的安全威胁后，需要对威胁进行赋值，即判断威胁出现的频率。应根据经验和有关的统计数据来对此进行判断。可以对威胁出现的频率进行等级化处理，不同等级分别代表威胁出现的频率的高低。等级数值越大，威胁出现的频率越高。表4提供了威胁出现频率的一种赋值方法。在实际的评估中，威胁频率的判断依据应根据历史统计或行业判断予以确定，并得到被评估方的认可。在评估中，需要综合考虑以下三个方面的因素：1)以往安全事件报告中出现过的威胁及其频率的统计。2)实际环境中通过检测工具以及各种日志发现的威胁及其频率的统计。3)近一两年来国际组织发布的对于整个社会或特定行业的威胁及其频率统计，以及发布的威胁预警。表4威胁赋值表5）；4高3）；2低1威胁几乎不可能发生；仅可能在非常罕见和5.2定义系统安全要求5.2.1主要任务应基于信息安全需求说明书，定义信息系统的信息安全要求。与之相关的任务主要有以下几方面内a)定义信息系统的安全边界及信息安全运行环境。b)明确信息安全管理要求，包括安全组织、人员安全、应急响应等。c)将信息安全需求在待建系统自身与外部环境、系统间进行分配，如图2所示。例如，对数字证书的安全需求应由依法成立的第三方电子认证机构提供。d)明确待建系统与外部系统之间的数据流，以及各数据流的信息安全防护需求。e)梳理对后续信息安全方案设计可能构成约束的条件，包括由外部系统施加的约束。例如，环境条件或环境限制、合同约束、习惯或惯例等。f)定义信息系统的信息安全功能要求与性能要求，性能要求应考虑峰值因素。g)制定信息系统的信息安全策略，包含信息安全目标。h)向用户说明，已定义的信息系统信息安全要求如何满足用户的信息安全需求，并得到用户认可。9DB14/T1252—2016图2信息安全需求与内外部系统的映射关系方框图5.2.2任务输出应编制以下文档：a)信息安全功能和性能说明书。b)以自然语言描述的待建信息系统的信息安全运行概念，包括但不限于。1)信息安全目标、策略。2)信息安全运行环境，包括物理环境、组织机构、人员等方面。3)对信息安全设计构成约束的前提条件。4)待建系统信息安全体系可能涉及到的机构和主要任务，包括可能对系统安全造成影响的机构及活动。5)待建系统中负责信息安全的有关岗位、职责及授权关系，以及可能对信息安全造成影响的其他岗位、职责及授权关系。6)待建系统中与信息安全有关的操作行为，包括操作流程。5.2.3方法应按照GB/T20282—2006的“指定安全要求”，采取以下方法，定义信息系统的信息安全要求：a)通过收集所有用于全面理解需求方安全要求所需的信息，获得对安全要求的理解。b)收集所有对系统安全产生影响的外部影响；标识出支配系统目标环境的法律、规则、策略和业务标准。c)标识出系统间的关系是如何影响安全的，任务的处理和运行概要应作为安全因素加以评估。d)定义系统的安全边界，包括梳理本机构的外部环境如何影响信息系统的安全。6设计安全方案DB14/T1252—20166.1设计安全体系结构6.1.1主要任务应基于已经定义的信息系统信息安全要求，设计信息系统的信息安全体系结构。与之相关的任务主要有：a)分析待建系统的信息安全体系结构。“定义系统安全要求”与“设计安全体系结构”的主要区别是，前者将信息安全要求分配到整个信息系统之中，只指明系统的功能，不定义系统的组件，而后者则明确了承担信息安全功能的各项组件。前者将目标系统视为“黑盒”，后者则创建信息安全体系的内部结构。图3和图4分别描述了两者的区别。b)在信息安全体系结构中分配安全服务，并为已分配的安全服务选择合适的安全机制，以便将此前确定的高层安全功能分解至低层功能，与高层功能相关的性能要求也应分解至低层。关于安全服务和安全机制的概念，可参见GB9387.2—1995。c)向用户说明，已设计的信息安全体系结构如何满足信息安全要求，并得到用户认可。d)开展信息安全风险评估，说明安全服务和安全机制如何抵御待建系统可能面临的安全风险，并设定信息安全风险处置目标，同时对信息系统的残余风险作出说明。图3定义系统安全要求展现方框图图4设计安全体系结构展现方框图6.1.2任务输出应编制以下文档：DB14/T1252—2016a)待建信息系统的信息安全体系结构。重点是明确系统内的各类信息安全组件，说明各组件提供的信息安全服务及可能的实现机制，包括各组件的逻辑功能和性能。此外，还需说明内外部的各类接口、信息流等。b)对信息安全体系结构的安全风险评估报告。6.1.3方法应采取以下方法设计信息系统的安全体系结构：a)按照GB9387.2—1995和GB/T18794（所有部分完成信息安全服务、机制在信息系统体系结构中的分配。信息安全服务是信息系统所能为用户提供的安全目标，是对用户信息安全需求的客观描述，如身份鉴别、访问控制、保密性、完整性、抗抵赖等。信息安全机制是为了实现相关安全服务而采取的技术措施。例如，为了实现“保密性”这一服务，可以采用“加密”这一机制，也可以使用“信息隐藏”这一机制。b)按照GB/T20984—2007的关于“设计阶段的风险评估”要求，根据规划阶段所明确的系统运行环境、资产重要性等，提出安全功能需求，对安全体系结构开展以下评估：1)是否符合系统建设规划，并得到最高管理者的认可。2)是否对系统建成后面临的威胁进行了分析，包括物理环境、自然的威胁，以及由于内、外部入侵等造成的威胁。3)安全需求是否符合规划阶段的安全目标，并基于威胁的分析，制定信息系统的总体安全策c)针对等级保护定级为第一级至第四级（含）系统的安全体系结构，按照GB/T25070—2010规定的相应等级保护安全设计技术进行安全机制的设计，设计目标考虑如下：1)第一级系统安全保护环境应实现定级系统的自主访问控制，使系统用户对其所属客体具有自我保护的能力。2)第二级系统安全保护环境在第一级系统安全保护环境的基础上，增加系统安全审计、客体重用等安全功能，并实施以用户为基本粒度的自主访问控制，使系统具有更强的自主安全保护能力。3)第三级系统安全保护环境应在第二级系统安全保护环境的基础上，通过实现基于安全策略模型和标记的强制访问控制以及增强系统的审计机制，使系统具有在统一安全策略管控下保护敏感资源的能力。4)第四级系统安全保护环境应建立一个明确定义的形式化安全策略模型，将自主和强制访问控制扩展到所有主体与客体，相应增强其他安全功能强度；将系统安全保护环境结构化为关键保护元素和非关键保护元素，以使系统具有抗渗透的能力。6.2开展详细的安全设计6.2.1主要任务应基于已设计的信息安全体系结构，开展详细的安全设计，细化到安全机制在信息系统中的具体实现。与之相关的任务主要有：a)分析所需的信息安全机制的强度。b)分析信息安全机制之间的互依赖性，如审计机制是监测机制的基础，身份标识是访问控制机制的基础。DB14/T1252—2016c)落实设计中的约束因素，并结合强度分析结果和互依赖性分析结果，研判相应强度的安全机制在系统中是否可实现。在此基础上，综合考虑成本、进度、性能、优先级等因素，确定整体信息安全体系结构的可行性。d)对于需要通过非技术性措施提供的安全服务，应列明相应的信息安全管理措施，并形成管理制度，例如应急响应、培训等。e)确定哪些机制需要通过现货产品提供，哪些机制则需要通过定制的产品提供，并明确产品的重要配置参数。f)确定哪些机制需要通过信息安全外包服务提供。g)对详细的信息安全设计进行有效性评估，以确保产品、管理制度与安全服务、安全机制之间具有对应性。h)依据信息化工程信息安全建设合同及有关的政策法规、标准，明确信息安全系统的指标规范。i)根据详细设计的结果，必要时对信息安全运行概念进行修正。6.2.2任务输出应编制以下文档：a)信息安全管理制度。b)信息安全外包服务需求说明书。c)信息安全系统指标规范，以用于评估安全方案后续实施的有效性。d)信息安全技术方案，细化到产品级，以指导信息安全系统的实施。e)信息安全系统实施方案，详细列明实施成本、工程进度等事项，并确定对资源保障（包括技术、人力等）和组织保障的需求。6.2.3方法应采取以下方法开展详细的安全设计：a)按照GB/T22239—2008，对不同等级的系统开展相应的安全方案设计：1)第一级系统的安全设计应满足等级保护一级的安全要求，依据风险分析的结果补充和调整安全措施。并以书面形式描述对系统的安全保护要求、策略和措施等内容，形成系统的安全方案。还应对安全方案进行细化，形成能指导安全系统建设、安全产品采购和使用的详细设计方案。2)第二级系统应在第一级系统的基础上，组织相关部门和有关安全技术专家对安全设计方案的合理性和正确性进行论证和审定，并且经过批准后才能正式实施。3)第三级系统应在第二级系统的基础上，指定和授权专门的部门对安全建设进行总体规划，制定近期和远期的安全建设工作规划，并应统一考虑安全保障体系的总体安全策略、安全技术框架、安全管理策略、总体建设规划和详细设计方案。上述文件应进行论证和审定，并定期调整和修订。4)第四级系统的详细安全设计要求与第三级系统相同。b)按照GB/T22081—2008中关于安全方针、信息安全组织、资产管理、人力资源安全、物理和环境安全、通信和操作管理、访问控制、信息系统获取、开发和维护、信息安全事件管理、业务连续性管理、符合性等方面的指南和一般原则，制定信息安全管理制度：1)根据业务目标制定清晰的方针指导，并通过在本机构中颁布和维护信息安全方针来表明对信息安全的支持和承诺。2)建立管理框架，以启动和控制本机构范围内信息安全的实施。指派安全角色，协调和评审整个机构内信息安全的实施。必要时在本机构范围内建立专家信息安全建议库，并发展与DB14/T1252—2016外部安全专家或组织（包括相关权威人士）的联系，以便跟上行业趋势、跟踪标准和评估方法，并且当处理信息安全事件时，提供合适的联络点。鼓励采用多学科方法，解决信息安全问题。3)对于所有资产指定责任人，并且赋予保持相应控制措施的职责。特定控制措施的实施可以由责任人适当地委派别人承担，但责任人仍有对资产提供保护的责任。4)任用前，在适当的岗位描述、任用条款和条件中指出安全职责；应对所有要任用、承包方人员和第三方人员的候选者进行充分的审查，特别是对敏感岗位的成员；使用信息处理设施的雇员、承包方人员和第三方人员应签署关于其安全角色和职责的协议。5)关键或敏感的信息处理设施应放置在安全区域内，并受到确定的安全周边的保护，包括适当的安全屏障和入口控制；应在物理上避免对这些设施的未授权访问、损坏和干扰，所提供的保护措施应与所识别的风险相匹配。6)建立所有信息处理设施的管理和操作职责和规程，包括制定合适的操作规程；必要时，应实施责任分割机制，以减少疏忽或故意误用系统的风险。7)信息、信息处理设施和业务过程的访问应在业务和安全要求的基础上予以控制，访问控制规则应考虑到信息传播和授权的策略。8)应在项目需求阶段识别所有安全要求，并证明这些安全要求的合理性，对这些安全要求加以商定，并且将这些安全要求形成文档，作为信息系统整体业务情况的一部分。9)所有雇员、承包方人员和第三方人员都应了解事件处理规程，以便报告可能对机构的资产安全造成影响的不同类型的事态和弱点。10)通过使用预防和恢复控制措施，将对本机构的影响减少到最低，并从信息资产的损失中恢复到可接受的程度；要对灾难、安全失效、服务丢失和服务可用性的后果进行业务影响分析，制定和实施业务连续性计划，以确保重要的运行能及时恢复。除了一般的风险评估过程之外，业务连续性管理应包括识别和减少风险的控制措施，以限制破坏性事件的后果，并确保业务过程需要的信息便于使用。11)信息系统的设计、运行、使用和管理都要受法律、法规以及合同安全要求的限制。7实施安全方案7.1开发和采购7.1.1主要任务应基于已完成的详细设计，开发定制产品，并采购现货产品。与之相关的任务主要有：a)选择合适的开发商，对定制产品进行开发。在选择开发商时，应重点考虑开发商的技术实力、信誉、可信度、安全资质、开发环境的安全保障水平、交付条件等因素。b)采购现货产品，重点考虑产品安全资质、成本、厂商信誉、可替代性等因素。c)对定制产品进行安全功能和性能测试。d)对开发和采购过程进行有效性评估。7.1.2任务输出应形成以下成果：a)获得定制产品，并将定制产品的开发文档、测试文档、使用说明书等进行归档。b)采购现货产品，并将现货产品的选型标准、采购过程文件等进行归档。DB14/T1252—20167.1.3方法应采取以下方法进行开发和采购：a)按照GB/T22239—2008，在自行开发软件时考虑下列要点：1)确保开发环境与实际运行环境物理分开，开发人员与测试人员分离，测试数据和测试结果受到控制。2)制定软件开发管理制度，明确说明开发过程的控制方法和人员行为准则。3)制定代码编写安全规范，并要求开发人员参照。4)提供软件设计的相关文档和使用指南，并由专人保管。5)确保对程序资源库的修改、更新、发布得到授权和批准。b)按照GB/T22081—2008，在外包软件开发时应考虑下列要点：1)许可协议、代码所有权和知识产权。2)所完成工作的质量和准确性的认证。3)第三方发生故障时的契约安排。4)审核所完成的工作质量和准确性的访问权。5)代码质量和安全功能的合同要求。6)在安装前，检测恶意代码。c)按照GB/T20984—2007对开发和采购过程进行评估，评估要点包括但不限于：1)法律、政策、适用标准和指导方针，直接或间接影响信息系统安全需求的特定法律；影响信息系统安全需求、产品选择的政府政策、国际或国家标准。2)信息系统的功能需要，安全需求是否有效地支持系统的功能。3)成本效益风险，是否根据信息系统的资产、威胁和脆弱性的分析结果，确定在符合相关法律、政策、标准和功能需要的前提下选择最合适的安全措施。4)评估级别，是否明确系统建设后应进行怎样的测试和检查，从而确定是否满足项目建设、实施规范的要求。7.2安全集成7.2.1主要任务开发完成定制产品并采购现货产品后，应在信息系统集成过程中同步集成信息安全产品。与之相关的任务主要有：a)根据信息安全技术方案，将定制产品和现货产品集成到信息系统之中，确保产品之间的互操作性，确保信息系统整体性能最佳。b)确保产品的安全特性已经激活，且安全参数已得到正确设置。c)对集成了信息安全产品的信息系统进行上线运行前的自测，测试信息安全系统是否达到指标规范的要求，验证信息安全系统对信息系统性能的影响，及时解决测评中发现的问题。d)建立模拟环境，开展线上自测，并及时解决测评中发现的问题。e)对信息系统管理员和用户进行培训。f)对安全集成过程进行有效性评估。7.2.2任务输出应形成以下成果：a)向用户交付信息系统时，应同步交付已完成自测的信息安全系统。b)应将线下自测和模拟线上自测的相关技术文档进行归档。DB14/T1252—20167.2.3方法应采取以下方法进行安全集成：a)按照GB/T22239—2008开展安全集成任务：1)指定或授权专门部门或人员负责安全集成任务的管理。2)制定详细的集成方案，并要求集成商正式地执行该方案。3)制定安全集成管理制度，明确说明安全集成过程的控制方法和人员行为准则。4)制定详细的系统交付清单，根据交付清单，对所交接的设备、软件和文档进行清点。5)对系统交付的控制方法和人员准则进行书面规定。6)制定或授权专门的部门负责系统交付的管理工作，并按照管理规定的要求完成系统交付工作。b)按照GB/T20984—2007对安全集成过程进行评估，评估要点包括但不限于：1)根据实际建设的系统，详细分析资产面临的威胁和脆弱性。2)根据系统建设目标和安全需求，对系统的安全功能进行验收测试。3)评价安全措施能否抵御安全威胁。4)评估是否建立了与整体安全策略一致的组织管理制度。5)对系统实现的风险控制效果与预期设计的符合性进行判断，如存在较大的不符合，应重新进行信息系统安全策略的设计与调整。7.3验收7.3.1主要任务组织对信息系统进行验收，并将信息安全作为验收的重要内容。与之相关的任务主要有：a)综合开发和采购、安全集成等阶段的有效性评估结果，对信息系统进行整体信息安全自评估。b)聘请第三方信息安全测评机构，依照合同规范和有关国家、行业标准，对信息系统进行安全测评。测评中如发现问题，应立刻整改。c)基于信息安全测评结果，组织召开信息安全评审会，对信息安全系统进行综合评审。评审会由本机构信息安全部门、业务部门、信息化部门、外部专家参加。评审通过后，由本机构负责信息安全的领导签字，信息系统方可投入运行。d)根据国家信息安全等级保护和涉密信息系统分级保护的要求，完成定级备案，并开展相应等级的建设和测评。测评结果按等级保护、分级保护的规定进行上报。e)对信息安全主管部门或业务主管、监管部门已明确提出相关要求的事项，还应通过这些部门组织的测评，如党政部门云计算服务应通过信息安全审查。7.3.2任务输出应确保信息系统及其中的信息安全系统可正式移交用户，并形成以下文档：a)验收报告，含测试报告、整改报告等。b)用户机构负责信息安全的领导的签字，表明其同意该信息系统投入运行。c)等级保护或分级保护测评备案材料。d)信息安全主管部门或业务主管、监管部门针对信息系统颁发的相关安全资质。7.3.3方法应采取以下方法，对信息系统安全进行验收。DB14/T1252—2016a)按照GB/T20984—2007，对规划阶段的安全威胁进行进一步细分，同时评估安全措施的实现程度，从而确定安全措施能否抵御现有威胁、脆弱性的影响。b)按照GB/T28448—2012，对不同保护等级的信息系统进行测试评估，验证信息系统是否符合GB/T22239—2008提出的技术要求和管理要求：1)测评的主要方法是访谈、检查、测试，表5给出了测评方法的深度与广度。表5测评方法的测评力度访谈的深度体现在访谈过程的严格和详细程访谈的广度体现在访谈谈覆盖不同类型的人员分检查有详细的分析、观察和研究，除了功能级上的文档、机制和活动还适当需要一些总体/概要设计信息；较全面检查有详细、彻底的分析、观察和研究，除了功能级上的文档、机制和活动外，还需要总体/概要和一些究，除了功能级上的文档、机制和活动外，还需要总体/概要和详细设计以检查的广度体现在检查不同类型的对象和同一测试的广度体现在被测测试覆盖不同类型的机制以及同一类型机制的2)在不同等级信息系统安全测评中，不同测评方法的测评力度各有不同，表6给出了不同安全等级信息系统的测评力度要求。DB14/T1252—2016表6不同等级信息系统的测评力度要求测评对象在种类和测评对象在种类和数量上抽样，种类和数测评对象在数量上抽测评对象在数量上抽样，在种类上全部覆盖测评对象在种类和测评对象在种类和数量上抽样，种类和数测评对象在数量上抽测评对象在数量上抽样，在种类上全部覆盖测评对象在种类和测评对象在种类和数量、范围上抽样，种类和数量都较多，范测评对象在数量和范测评对象在数量、范围上抽样，在种类上c)按照GB/T28449—2012，实施信息系统安全等级保护测评准备活动、方案编制活动、现场测评活动、报告编制活动，明确相关的工作流程、工作任务、每项任务的输出文档以及活动中双方的职责。d)按照GB/T30273—2013，对信息系统安全技术保障措施、安全管理保障措施和安全工程保障措施等进行测评。1)安全技术保障措施评估要求是：——评估系统中安全审计机制是否具有安全审计自动响应、安全审计数据产生、安全审计分析、安全审计查阅、安全审计事件选择、安全审计事件存储等功能。——评估系统的通信机制是否具有原发抗抵赖和接收抗抵赖功能，以确保通信发起者不能否认发送过信息，又确保收信者不能否认收到过信息。——评估系统的密码支持机制是否满足密钥管理、密码运算等要求，即基于国密算法和密钥长度来产生密钥、分配密钥、访问密钥和销毁密钥。——评估系统的数据保护机制是否能够保护输入、输出和存储期间的用户数据，以及和用户数据直接相关的安全属性，包括系统的访问控制策略、访问控制功能、数据鉴别机制、信息流控制策略、信息流控制功能等。——评估系统的标识和鉴别功能，确保用户与正确的安全属性相关联(如身份、组、角色、安全或完整性等级)。——评估系统的安全管理机制是否满足安全功能管理、安全属性管理、安全数据管理、安全管理角色等功能要求。——评估系统的隐私机制是否具有匿名、假名、不可观察性、不可观察性等功能。DB14/T1252—2016——评估系统的安全功能保护机制是否具有抽象机测试、失败保护、安全数据保密性、安全数据完整性、安全数据可用性、安全数据传输、物理保护、可信恢复、重放检测、参照仲裁、域分离、状态同步协议、时间戳、安全数据复制的一致性、安全功能自检等功能。——评估系统的资源利用机制是否支持资源处理能力或存储能力，以防止由系统故障引起的系统资源不可用。——评估系统的访问控制机制是否具有会话锁定、系统访问旗标、系统访问历史、会话建立等功能。——评估系统的可信路径、可信通道机制是否为用户和系统安全功能之间建立了可信通信路径，以及为系统安全功能和其他可信系统组件、产品之间建立了可信通信信道。2)安全管理保障措施评估要求是：——评估本机构是否建立了一套风险管理体系，通过对象确立、风险评估和风险控制三个基本步骤，并将沟通与监控贯穿于这三个步骤中，进行信息安全风险管理与防范，将系统风险降低到可接受的水平。——评估本机构是否围绕信息安全策略的制定和维护实施了管理，以便于为信息安全提供符合业务要求和相关法律法规的管理指导和支持。——评估本机构的信息安全管理是否得到了机构最高管理层的承诺和支持，并建立了完善的信息安全组织结构，包括建立相应的岗位、职责和职权。此外，还应评估是否建立了完善的内部和外部沟通协作组织和机制，同机构内部和外部信息安全所有相关方进行充分沟通、学习、交流和合作等。——评估本机构是否建立了规范的人员安全管理制度，对机构的聘用人员进行严格的审查，并明确了人员的安全职责和保密要求。还应评估本机构是否开展了人员安全意识培训和教育，并建立了考核和奖惩机制，使信息安全融至组织机构的整个环境和文化中，减少有意、无意的内、外部威胁。——评估本机构是否通过规范资产的管理和使用来保障资产的安全，以最终确保系统的安全。——评估本机构是否建立了物理安全、区域安全制度，包括严格的物理访问控制措施，以防止非法访问、危害及干扰系统运行。还应评估本机构在防火、防水、温湿度、防雷等方面的安全措施，以保证基础设施安全，确保系统持续运行。——评估本机构是否建立了有效的监督体系，以监督验证信息安全工作对相关法律法、政策标准等要求以及本机构所制定的信息安全策略体系的符合性以及执行的效果。——评估本机构是否建立了完善的信息安全规划管理体系，以规划和指导本机构的信息安全工作。重点评估信息安全规划是否基于本机构的业务要求和风险管理要求，以及这些规划是否是本机构整体规划的综合组成部分。——评估本机构是否将信息安全综合至系统开发的整个生命周期中，是否在系统的需求分析、设计、实施和交付中考虑信息安全。——评估本机构是否具有业务连续性管理制度，以防止业务过程中断，保护关键业务流程不会受信息系统重大失效或自然灾害的影响，并确保及时恢复。还应评估本机构是否制定了业务连续性计划，以保证业务过程能够在所需的时间范围内恢复。3)安全工程保障措施评估要求是：——评估是否已明确地标识系统的安全需求。——评估是否为系统架构者、设计者、实施者或用户提供了他们所需的安全信息。——评估是否所有的安全机制都能对应到安全体系结构，并且安全体系结构有具体的安全机制来保证。——评估最终的详细安全设计结果是否为实施系统提供了充分的组件和接口描述信息。DB14/T1252—2016——评估是否把确保系统预想的安全已被集成到系统设计中，最终的运行状态中的系统也确实达到了这种安全要求。——评估是否建立了安全态势感知系统，确保所有的违规、尝试违规或可能导致违背安全的错误能被及时发现。——评估在信息化工程安全建设之中，是否建立了协调机制，确保各方了解并参与到了安全工程活动中。e)按照GB/T30976.1—2014，对工业控制系统信息安全进行评估。1)开发与采购过程的评估要求是：——评估是否梳理了直接或间接影响工业控制系统信息安全的有关法律、政策、适用标准和指导方针。——评估工业控制系统信息安全需求是否能够有效地支持系统的功能。——评估工业控制系统信息安全措施是否基于风险评估而选择。——评估是否明确了工业控制系统信息安全应该达到的级别。2)系统实施过程的评估要求是：——对实际建设的工业控制系统进行风险评估，详细分析系统（资产）面临的威胁和脆弱性。——根据系统建设目标和信息安全需求，对系统的信息安全进行验收测试，评估安全措施能否抵御安全威胁。——评估是否建立了与整体安全策略一致的组织机构管理制度。——对系统实现的风险控制效果与预期设计的符合性进行判断，如存在较大的不符合，应重新风险评估。f)按照GB/T30976.2—2014，对工业控制系统信息安全进行验收，验收过程划分为验收准备、风险分析与处置、能力确认三个阶段。1)验收准备是验收有效性的重要保证，是验收工作的开始，主要工作包括：——各参与方共同明确验收目标，核查相关文档。——确定验收目标和范围。——文档准备。查验是否已完成所有的内部测试，并提供了可供复查的测试报告或有关机构的评估报告。2)风险分析与处置阶段是验收工作的核心内容，主要是结合评估阶段给出的评估结论和改进措施，判断是否有相应的风险处置措施，并提出解决方案。——评估风险分析模型和风险计算方法是否能正确反应用户的行业安全特点，以及核心业务系统所处的内、外部环境安全状况。——评估用户确认的信息、数据及相关文档资料是否及时得到了准确反馈。——评估安全整改措施是否考虑了安全风险的严重程度、加固措施实施的难易程度、降低风险的时间紧迫程度、所投入的人员力量及资金成本等因素。——评估残余安全风险是否控制在可接受的范围内。8开展安全运维8.1信息安全风险评估和监测应采取以下措施，对信息系统开展信息安全风险评估和监测，了解和控制运行过程中的安全风险：a)资产评估：在真实环境下较为细致的评估。包括实施阶段采购的软硬件资产、系统运行过程中生成的信息资产、相关的人员与服务等，本阶段资产识别是前期资产识别的补充与增加。DB14/T1252—2016b)威胁评估：应全面地分析威胁的可能性和影响程度。对非故意威胁导致安全事件的评估可以参照安全事件的发生频率；对故意威胁导致安全事件的评估主要就威胁的各个影响因素作出专业判断。c)脆弱性评估：是全面的脆弱性评估。包括运行环境中物理、网络、系统、应用、安全保障设备、管理等各方面的脆弱性。技术脆弱性评估可以采取核查、扫描、案例验证、渗透性测试的方式实施；安全保障设备的脆弱性评估，应考虑安全功能的实现情况和安全保障设备本身的脆弱性；管理脆弱性评估可以采取文档、记录核查等方式进行验证。d)风险计算：根据本标准的相关方法，对重要资产的风险进行定性或定量的风险分析，描述不同资产的风险高低状况。e)定期执行或当组织的业务流程、系统状况发生重大变更时及时进行风险评估。重大变更包括以下情况（但不限于）：1)增加新的应用或应用发生较大变更。2)网络结构和连接状况发生较大变更。3)技术平台大规模地更新。4)系统扩容或改造。5)发生重大安全事件后，或基于某些运行记录怀疑将发生重大安全事件。6)组织结构发生重大变动对系统产生了影响。8.2事件处理和应急响应应采取以下措施，按照GB/Z20985—2007，对信息系统中出现的安全事件进行处理：a)制定应急响应计划，明确本机构内与应急响应有关的组织架构，定义需要报告的信息安全事件，提出应急响应流程，为应急响应提供必要的应急资源和管理支持。应急响应计划应得到本机构管理层批准，并保持定期更新。b)当发现可疑信息安全事件时，按照应急响应计划，及时向本机构的应急响应部门报告。当发生影响较大的安全事件时，向国家和地方应急响应组织及有关信息安全主管部门报告。c)开展应急响应培训。d)定期演练应急响应计划，根据应急演练情况完善信息安全系统。e)保存信息安全事件证据，便于开展后续的调查取证工作。8.3灾难备份和业务连续性计划应采取以下措施，按照GB/T20988—2007，对信息系统进行备份，做好信息系统的业务连续性管理：a)制定灾备恢复策略，根据系统的重要性、实时性等因素选择合适的灾难备份机制。b)为灾备恢复提供必要的人力、技术、设备等资源准备。c)制定业务连续性计划，确保信息系统对本机构职能和业务的核心支撑能力在重大信息安全事件中不受到明显影响。8.4配置管理应采取以下措施，对信息系统实施配置管理：a)制定信息系统配置管理计划，明确配置管理流程，定义信息系统的重要配置项。配置管理计划应安全保存，防止非授权泄露。b)制定、记录并维护信息系统的基线配置。c)保留信息系统基线配置的历史版本，便于必要时恢复历史配置。DB14/T1252—20168.5变更管理信息系统及其运行环境发生明显变化时，应评估其风险，对信息系统实施变更管理：a)明确重大变更的类型，包括系统升级、增加新的功能、本机构组织结构有重大调整、发现新的威胁或脆弱性等。b)在实施变更前，对拟变更事项进行分析，必要时进行测试，判断该变更事项对信息系统安全带来的潜在影响。c)制定书面流程，便于对变更时可能出现的意外情况进行及时处理，并规定变更失败时的系统恢复流程。d)将变更事项、变更计划等提交本单位管理层批准。e)严格根据已批准的变更计划实施系统变更，留存全部变更记录。8.6维修维护信息系统或其组件进行维修维护时，应采取以下措施，防范维修维护过程中可能出现的安全风险：a)审批和监视所有维修维护行为，包括现场维修维护、远程维修维护，以及对设备的异地维修维护。b)将信息系统组件转移到外部进行维修维护时，应事先得到本机构管理层批准，并评估其中所含信息的敏感程度，必要时作出信息净化处理。含有特别重要的敏感信息或涉密信息的重要组件不得交由无资质的机构进行维修维护。c)对维修维护过程作出全面记录，包括日期和时间、维修维护人员姓名、陪同人员姓名、对维修维护活动的描述、被转移或替换的设备列表（包括设备标识号）等信息。d)对维修维护人员带入机构内的维修维护工具进行检查，以确保该工具不含有恶意功能。维修维护工具带出机构时，应进行信息净化处理。对于重要机构，维修维护工具一经带入，不得带出。e)远程维修维护应采取强身份鉴别机制，所有远程维修维护活动应进行审计。远程维修维护结束后，应立即终端网络连接。9确保废弃过程的安全9.1信息安全风险评估应确保对信息系统的过时或无用部分进行安全废弃处理，以防止敏感信息非授权泄露。系统废弃前，应开展风险评估，重点关注以下内容：a)确定废弃对象，包含被废弃的硬件、软件甚至是整个系统，包含其中所含的信息。b)确定废弃对原有信息系统带来的威胁和风险，评估不废弃可能对信息系统造成的影响。c)综合考虑信息系统的重要性、信息的敏感性等因素，对废弃方式作出判断，如历史信息如何归档保存、被废弃组件是否可再用等。应关注局部信息不敏感，但大量信息汇聚后变为敏感的情况。9.2业务迁移与连续性信息系统因各种原因废弃后，并不意味信息系统支撑的原有功能消亡。如需要建设新的信息系统承接原有功能，应采取以下措施，确保业务平稳、安全迁移：a)在新信息系统建设完成、通过验收并正式上线前，不得关闭原有信息系统。新信息系统上线运行后，应留出过渡时间封存旧信息系统，便于在紧急情况下依然可以重新启动旧信息系统。如DB14/T1252—2016因物理环境、人力资源等条件限制，新旧系统不能同时并存，应采取分步骤、分阶段方式，实现边废弃、边建设。b)如出现对软硬件或服务提供商过度依赖，导致系统迁移受制于人、明显违背市场经济规则的情况，应及时上报国家和地方信息安全主管部门作出处理。9.3介质处理在废弃信息系统时，应采取以下措施，保护被废弃介质中存储信息的安全：a)对存储敏感信息的介质进行妥善保存，或采用安全方式进行处置，如焚烧、破碎等，或在净化信息后重复利用。b)对含有特别重要的敏感信息或涉密信息的重要介质，选择有资质的机构