《信息安全技术ICT供应链安全风险管理指南(GB-T 36637-2018).docx》由会员分享，可在线阅读，更多相关《信息安全技术ICT供应链安全风险管理指南(GB-T 36637-2018).docx（31页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、GB/T XXXXXXXXXICS35.040L 80中华人民共和国国家标准GB/T XXXXXXXXX信息安全技术 ICT供应链安全风险管理指南Information security technologyGuidelines for the information and communication technology supply chain risk management本稿完成日期：2017-10-25XXXX-XX-XX发布XXXX-XX-XX实施目次前言II引言III1 范围12 规范性引用文件13 术语和定义14 缩略语25 总则26 ICT供应链安全风险管理过程36.1 概
2、述36.2 背景分析46.3 风险评估46.4 风险处置86.5 风险监督和检查86.6 风险沟通和记录87 ICT供应链安全风险控制措施97.1 控制措施应用原则97.2 技术安全措施97.3 管理安全措施11附 录 A（资料性附录） ICT供应链概述17附 录 B（资料性附录） ICT供应链安全威胁19附 录 C（资料性附录） ICT供应链安全脆弱性22参考文献25前言本标准按照GB/T 1.1-2009标准化工作导则 第1部分：标准的结构和编写给出的规则起草。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由全国信息安全标准化技术委员会（SAC/TC2
3、60）提出并归口。本标准起草单位：中国电子技术标准化研究院、中国科学院软件研究所、联想（北京）有限公司、华为技术有限公司、浙江蚂蚁小微金融服务集团股份有限公司、阿里巴巴（北京）软件服务有限公司、北京京东叁佰陆拾度电子商务有限公司、中国信息通信研究院、微软（中国）有限公司、浪潮电子信息产业股份有限公司、国家信息技术安全研究中心、英特尔（中国）有限公司、阿里云计算有限公司、中国信息安全认证中心、中国科学院信息工程研究所信息安全国家重点实验室。 本标准主要起草人：胡影、刘贤刚、卿斯汉、叶润国、孙彦、李汝鑫、薛勇波、王昕、白晓媛、黄少青、刘陶、赵江、杨煜东、赵丹丹、张凡、陈星、宁华、樊洞阳、陈晔、陈雪
4、秀、吴迪。引言随着信息通信技术的普及应用，加强ICT供应链的安全可控保障变得至关重要。目前，世界各国和ICT行业已普遍认识到，ICT供应链存在安全风险，需要加强ICT供应链安全管理，增强客户对ICT供应链的信任。与传统供应链相比，ICT供应链具有许多不同的特点，例如：一是ICT供应链涵盖了ICT产品服务的全生命周期，不仅包括传统供应链的生产、销售、交付等供应阶段，也包括产品服务的设计开发阶段和售后运维阶段。二是许多ICT产品由全球分布的供应商开发、集成或交付，ICT供应链的全球分布性使得客户对供应链的理解能力和安全风险控制能力在下降。三是传统供应链主要关注如何将产品有效交付给客户，或者供应链是
5、否具有健壮性，而ICT供应链安全更关注是否会将额外功能注入产品或服务，交付的产品或服务是否一致等。这些特点使得ICT供应链比传统供应链存在更多的安全风险，需要对ICT供应链的安全风险加强管理。本标准在GB/T 31722-2015信息技术 安全技术 信息安全风险管理的指导下，参考了相关国内外标准的技术内容，旨在针对ICT供应链的特点，细化ICT供应链安全风险管理的过程和控制措施，包括列举ICT供应链的主要安全威胁和脆弱性，细化ICT供应链安全风险管理的步骤和实施细则，给出ICT供应链安全风险控制措施集合等，为ICT产品服务的需方或供方提供管理ICT供应链安全风险的实施指南。ICT产品和服务的供
6、方或需方宜在满足GB/T 31722-2015规定的组织信息安全风险管理要求的基础上，按照本标准规范对ICT供应链的安全风险进行管理。关于信息技术产品供应方的安全行为准则不在本标准中规范。本标准推荐在关键信息基础设施或重要信息系统中使用。然而，由于个别需要和相关性，组织可选择将指南应用到其他系统或特定组件，不过应用本指南的控制措施可能会增加组织和外部供应商的潜在成本，需要组织在成本和风险间进行权衡。III信息安全技术 ICT供应链安全风险管理指南1 范围本标准给出了信息通信技术（以下简称ICT）供应链的安全风险管理过程和控制措施。本标准适用于重要信息系统和关键信息基础设施的ICT供方、运营者对
7、ICT供应链进行安全风险管理，也适用于指导ICT产品、服务的供方和需方加强供应链安全管理，同时还可供第三方测评机构对ICT供应链进行安全风险评估时参考。2 规范性引用文件下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T 24420-2009 供应链风险管理指南GB/T 31722-2015 信息技术 安全技术 信息安全风险管理3 术语和定义GB/T 25069-2010和GB/T 31722-2015界定的以及下列术语和定义适用于本文件。3.1需方 acquirer从其他组织获取
8、产品或服务的组织或个人。注1：获取可能涉及或不涉及资金交换。注2：重要信息系统或关键信息基础设施的运营者，通常是从ICT供方获取ICT产品或服务的需方。3.2ICT供方 information & communication technology supplier提供信息通信技术产品或服务的组织。注1：供方也可称供应商、供应方。注2：供方可以是组织内部的或外部的。注3：ICT供方包括产品供应商、服务提供商、系统集成商、生产商、销售商、代理商等。3.3 供应关系 supplier relation是指在需方和供方之间的协议，可用于开展业务，提供产品或服务，实现商业收益。 注1：需方和供方可以是同
9、一个机构。 注2：在供应链中，上游机构的需方同时也是下游机构的供方。终端客户是可以理解为一种特殊的需方。3.4ICT供应链 ICT supply chain即ICT产品和服务的供应链，是指为满足供应关系通过资源和过程将需方、供方相互连接的网链结构，可用于将信息通信技术的产品、服务提供给需方。3.5供应链安全风险 supply chain security risk供应链安全威胁利用供应链及其管理体系中存在的脆弱性，导致供应链安全事件的发生及其对组织造成的影响。3.6供应链安全风险管理 supply chain security risk management指导和控制组织与供应链安全风险相关问
10、题的协调活动。3.7ICT供应链生命周期 ICT supply chain life cycleICT产品或服务从无到有再到废弃的全生命周期涉及的供应链活动。注1：ICT供应链生命周期，不仅包含传统供应链的生产、集成、仓储、销售、交付等流程，还包括产品或服务设计开发的过程，及产品或服务交付后的运营维护过程。注2：ICT供应链，通常以ICT产品或服务的规划或设计为起点，经过开发、采购、外包、生产、集成、仓储、销售、交付等环节将产品或服务交付给需方，并对产品或服务进行安装、维护等直至其废弃。3.8ICT供应链基础设施ICT supply chain infrastructure由组织内的硬件、软件
11、和流程等构成的集合，用于构建产品或服务的开发、生产、测试、部署、维护、报废等系统生命周期的环境。注1：ICT供应链基础设施，主要包括组织内部支撑ICT供应链生命周期的信息系统和物理设施，如供应链管理信息系统、采购管理系统、软件开发环境、零部件生产车间、产品仓库等。注2：ICT供应链信息系统，属于ICT供应链基础设施，是由计算机、其他信息终端、相关设备、软件和数据等组成的，按照一定的规则和程序支撑产品或服务的开发、采购、生产、集成、仓储、交付、维护、外包等供应链生命周期的系统。4 缩略语以下缩略语适用于本文件。ICT：信息通信技术（Information & Communication Tech
12、nology）SCSRM：供应链安全风险管理（Supply Chain Security Risk Management）5 总则ICT供应链是一个全球分布的，具有供应商多样性、产品服务复杂性、全生命周期覆盖性等多维特点的复杂系统，相关概述说明详见附录A。在供应链中，一个组织可能既是上游组织的需方，也是下游组织的供方，与其上游、下游均存在供应关系。供应链的最终需方也被称为终端客户。为终端客户直接提供产品或服务的供应商是一级供应商，一级供应商与终端客户之间存在直接供应关系。一级供应商的供应商为二级供应商，依此类推，他们与终端客户存在间接供应关系。而随着供应商层级的增多，需方对ICT供应链的透明度
13、、理解能力都在降低，从而使得对ICT供应链安全风险的控制能力也在下降。从终端客户的角度来看，终端客户的一级供应商或ICT供应链中的品牌拥有者宜承担供应链安全的主要责任。因此，本标准主要对重要信息系统和关键信息基础设施的ICT供方管理其供应链安全风险进行规范，而关键信息基础设施的运营者则可在自身安全风险管理中考虑其供应链安全风险管理。ICT供应链相比传统供应链面临更多的安全风险，宜加强对ICT供应链安全风险管理，重点实现以下目标：a） 完整性：确保在ICT供应链所有环节中，产品、系统、服务及其所包含的组件、部件、元器件、数据等不被植入、篡改、替换和伪造。b） 保密性：确保ICT供应链上传递的信息
14、不被泄露给未授权者。c） 可用性：确保需方对ICT供应链的使用不会被不合理的拒绝。一方面，确保ICT供应链按照与需方签订的协议能够正常供应，不易被人为或自然因素中断，也称为可供应性；另一方面，即使在ICT供应链部分失效时，仍能保持连续供应且快速恢复到正常供应状态的能力，也称为弹性。d） 可控性：是指需方对ICT产品、服务或供应链的控制能力。可控性包括供应链可追溯性，即一旦ICT供应链发生问题，可以有效识别哪个环节、哪个供应商、哪个组件出现了问题，并可进行追溯或修复。可控性，也包括需方对供应链信息的理解或透明度，用户对自己数据的支配能力，用户对自己所拥有和使用产品的控制能力，用户对使用产品和服务
15、的选择权，产品和服务的行为与合同协议相符等。6 ICT供应链安全风险管理过程6.1 概述ICT供应链安全风险管理过程由背景分析（6.1）、风险评估（6.2）、风险处置（6.3）、风险监督和检查（6.4）、风险沟通和记录（6.5）五个步骤组成，如图1所示。组织宜在满足GB/T 31722规定的组织信息安全风险管理要求的基础上，按照图1所示建立ICT供应链风险管理过程，但考虑到组织实际情况，也可将ICT供应链安全风险管理分散到对ICT供应链生命周期各环节、ICT供应链基础设施、外部供应商的风险管理。图1 ICT供应链安全风险管理过程6.2 背景分析ICT供应链安全风险管理是组织整体风险管理的组成部
16、分,组织宜结合实际情况建立ICT供应链安全风险管理的背景，包括基本准则、范围边界和风险约束等。其中，基本准则是ICT供应链安全风险管理需要遵循的准则，如风险评价准则、影响准则、风险接受准则等；范围边界宜明确供应链管理涉及的供应商、ICT供应链基础设施、产品/服务/组件等；风险约束宜确定对执行ICT供应链安全风险管理活动需满足的约束，包括组织约束和ICT供应链约束。宜考虑以下因素以建立背景： 组织战略、业务目标、职能架构；供应链 组织流程（安全方面、质量方面等）； 组织的整体风险管理方法、安全策略、信息安全方针； 基于组织战略的ICT SCSRM业务目标、职能架构、组织流程、供应链结构； ICT
17、 SCSRM策略，包括但不限于购置、采购、信息安全、质量、物流等内容； 供应链内部和外部利益相关者及其价值观和风险偏好； 供应商信息，包括资质、信用、支付能力、管理状况、地理分布、合作历史等； 供应链在资金、时间、人力、过程、系统和技术等方面的能力和约束； ICT供应链基础设施、信息流和决策过程； 供应链管理的历史数据； 适用的法律法规。6.3 风险评估6.3.1 总体考虑背景分析后组织能够开展风险评估，对ICT供应链所面临的安全风险进行风险识别（6.2.1）、风险分析（6.2.2）和风险评价（6.2.3）。风险评估可多次迭代直至结果满足要求。6.3.2 风险识别6.3.2.1 资产识别组织宜
18、识别ICT供应链的关键资产，此类资产对组织的业务功能有直接影响，一旦被禁用或受损，可能导致组织的产品或服务失效或质量下降。宜考虑以下因素以识别关键资产： 组织的关键业务； 对业务至关重要的系统、组件（硬件、软件和固件）和流程； 依赖性分析和评估，确定可能需要在系统架构中进行加固的组件； 关键系统、组件、信息的获取和审核，例如其制造或开发位置、物理和逻辑交付路径、与关键组件相关的信息流等； 将已识别的关键组件与ICT供应链信息、历史数据和系统开发生命周期相关联，以确认ICT供应链关键路径； 关键功能依赖的功能，如软件补丁使用的数字签名技术等； 对所有接入点的确认，识别并限制对关键功能、组件的直接
19、访问（如最小特权执行）； 在系统生命周期内可能发生的恶意变更。6.3.2.2 威胁识别ICT供应链安全威胁可能是对ICT供应链直接或间接的攻击，也可能是偶发的或意外的安全事件。ICT供应链安全威胁可以通过来源、类型等属性来描述。a） 威胁来源识别ICT供应链安全威胁如表1所示，主要来源于环境因素、供应链攻击和人工错误。其中，环境因素是由环境原因造成的供应链安全问题。供应链攻击是攻击者通过供应链发起的网络或物理攻击。供应链的设计、开发、生产、交付、运维、报废等任意环节都可能遭受此类攻击。人工错误，是指由于内部人员、供应商人员、外包人员安全意识不足，没有遵循供应链安全规章制度和操作流程而导致的安全
20、问题。表1 ICT供应链安全威胁来源列表来源示例环境因素静电、灰尘、潮湿、鼠蚁虫害、电磁干扰、洪灾、地震、台风、意外事故等环境危害或自然灾害；软件、硬件、数据、通讯线路、电力、云计算平台等基础设施的故障；贸易管制、限制销售、知识产权等国际环境因素；罢工等人为突发事件。供应链攻击假冒伪造者假冒伪劣者试图获取和销售ICT伪造组件用于盈利，特别是假冒伪劣者寻找处理机构、购买库存积压产品，获得ICT组件的设计蓝图，通过灰色销售渠道提供给购买者。恶意攻击者恶意攻击者试图渗透或中断ICT供应链，植入恶意功能或进行未授权访问，来收集信息或造成损坏商业间谍商业间谍等针对供应链或产品、服务、组件等发起网络或物理
21、攻击，窃取知识产权等敏感信息，破坏业务操作或系统。内部人员不满的或有预谋的内部人员对产品服务进行恶意篡改、植入、替换、伪造或者破坏；采用自主或内外勾结的方式盗窃软件代码、设计蓝图或文档等知识产权信息销售或转移给竞争对手或外部情报机构，以获取利益。供应商或外包人员供应商或外包人员利用供应链管理的脆弱性，从ICT供应链的开发、生产、交付、销售、维护、返回等环节，对ICT供应链进行恶意攻击，或对产品的上游组件进行恶意篡改或伪造。人工错误内部人员、供应商人员或外包人员由于缺乏培训、专业技能不足、不具备岗位技能要求而导致ICT供应链基础设施故障，及由其引发的供应链中断。b） 威胁类型识别组织宜识别ICT
22、供应链可能面临的安全威胁类型，表2给出了典型的ICT供应链安全威胁类型，主要包括：恶意篡改、假冒伪劣、供应中断、信息泄露、违规操作和其他威胁。威胁类型的更多信息参见附录B。表2 ICT供应链安全威胁类型列表类型描述威胁子类示例恶意篡改在ICT供应链的设计、开发、采购、生产、仓储、物流、销售、维护、返回等某一环节，对ICT产品或上游组件进行恶意篡改、植入、替换等，以嵌入包含恶意逻辑的软件或硬件。恶意程序、硬件木马、外来组件被篡改、未经授权的配置、供应信息篡改假冒伪劣ICT产品或上游组件存在侵犯知识产权、质量低劣等问题。不合格产品、未经授权的生产、假冒产品供应中断由于人为或自然的原因，造成ICT产
23、品或服务的供应量或质量下降，甚至出现ICT供应链中断或终止。人为或自然的突发事件中断、基础设施故障、国际环境影响、不正当竞争行为、不被支持的组件表2（续） ICT供应链安全威胁类型列表类型描述威胁子类示例信息泄露ICT供应链上传递的敏感信息被非法泄露。供应链或生态圈的共享信息泄露、供应链商业秘密泄露违规操作ICT供方的违规操作行为。供应商违规收集或使用用户数据、滥用大数据分析、非法远程控制用户产品、影响市场秩序其他威胁ICT供应链的全球分布性为供应链安全带来了新的威胁或挑战需方安全风险控制能力下降、法律法规差异性挑战、全球化外包管理挑战6.3.2.3 脆弱性识别ICT供应链脆弱性是在产品或服务
24、的设计、开发、生产、交付、运维、报废等任意供应链环节能被威胁利用的缺陷。脆弱性是资产本身的特性，仅被威胁利用时会产生危害，没有相应威胁时可能不需要实施控制措施，但宜关注和监视其变化。ICT供应链脆弱性既包括产品或服务在其生命周期内的脆弱性，也包括ICT供应链脆弱性。ICT供应链脆弱性可能存在于： 产品或服务生命周期中的系统或组件； 直接影响系统生命周期的开发和运维环境； 运输ICT产品或组件的物流和交付环境，包括逻辑或物理的。脆弱性识别宜围绕ICT供应链关键资产展开，针对每一项需要保护的资产，识别可能被威胁利用的脆弱性，并对其严重程度进行评估。表3给出了一些ICT供应链脆弱性示例，详见附录C。
25、脆弱性识别时需要特别关注能使攻击者获得供应链敏感信息、植入恶意组件、触发系统运行故障、访问关键功能依赖的支撑或关联组件的脆弱性。表3 ICT供应链脆弱性种类子类脆弱性示例供应链生命周期的脆弱性开发阶段脆弱性ICT产品或服务在设计、开发阶段可能存在安全隐患，如：产品或服务设计时未对安全需求、安全威胁进行分析，开发时未遵循安全开发流程，没有建立完善的配置管理控制产品或组件的变更，没有适当的操作流程来检测伪造品、替换零件，合作或外包开发没有明确安全要求，第三方软件使用前没有进行安全检查等。供应阶段脆弱性ICT产品或服务在生产、仓储、运输、销售等供应阶段可能存在安全隐患，如：采购时无法识别被篡改或伪造
26、的组件，生产环境的物理安全访问控制不严，采用了不可靠或不安全的仓储商，运输时产品被植入、篡改或替换，经销商未经授权私自预装程序等。运维阶段脆弱性ICT产品或服务在维护、返回等运维阶段可能存在安全隐患，如：产品返回维修时被植入、篡改或替换，缺乏对安全漏洞的应急响应能力，售后人员盗窃用户数据等。供应链基础设施的脆弱性供应链管理脆弱性由于ICT供应链安全管理缺乏或管理不严，可能存在安全隐患，如：未完全建立供应链安全管理制度和流程，缺乏供应链安全责任部门和人员，在选择供应商时未考虑网络安全要求，没有对供应商的绩效和安全风险进行定期评估，缺乏对外包项目、外包人员的安全规定等。表3（续） ICT供应链脆弱
27、性种类子类脆弱性示例供应链基础设施的脆弱性ICT上下游脆弱性供应链或生态圈的供应商安全能力参差不齐，ICT供应链整体安全水平不高，如：一些供应商的产品安全标准和供应链安全管理流程缺乏，也有的供应商不能及时发现安全缺陷并进行修复和响应等；由于上游企业安全能力不足、产品市场被部分企业垄断、部分下游企业安全检测能力有限、长期合作独家供应商造成依赖等原因，导致下游供应商难以控制和追溯上游的供应链风险。供应链信息系统脆弱性组织的ICT供应链信息系统，可能存在安全隐患，如：未对供应商访问供应链相关信息进行访问控制，个人信息保护未满足相关法规标准要求，未对个人信息访问和使用进行控制，供应链信息不透明或阻塞，
28、信息系统存在漏洞等。供应链物理安全脆弱性厂房、仓库、数据中心、机房的位置，缺少抵御自然灾害或人为破坏等的能力。6.3.2.4 现有安全措施识别组织宜识别ICT供应链现有或已计划的安全措施，并对安全措施的有效性进行确认。宜考虑以下活动以实现现有或计划的安全措施识别： 检查ICT供应链安全措施相关的制度文件，了解计划采取哪些安全措施； 访谈组织的信息安全人员和供应链管理人员，了解实际采取了哪些安全措施； 现场核查验证已采取的ICT供应链安全措施，确认安全措施是否在正确和有效地工作； 参考供应链或网络安全相关标准规范，判断已实施的安全措施是否满足相关标准规范要求。6.3.3 风险分析风险分析包括可能
29、性分析、后果分析和风险估算。可能性是威胁利用脆弱性导致安全事件发生的概率。可能性分析应从两个角度进行，一是ICT供应链本身受到损害的可能性，例如可能影响关键组件使用或增加知识产权被窃取风险；二是供应链内的产品、服务、系统或组件受到损害的可能性，例如系统被植入恶意代码或组件被电击损坏。后果分析针对已识别的ICT供应链安全事件，分析事件的潜在影响。组织宜从资产的重要性，引发安全事件的威胁来源的特征，已识别的脆弱性，现有或已计划安全措施反映出的组织对事件的敏感性等方面进行后果分析。风险估算为ICT供应链安全风险的可能性和后果赋值，风险估算应基于可能性分析和后果分析的结论进行。注：见GB/T 3172
30、2-2015中8.2.2。6.3.4 风险评价风险评价将风险估算结果与风险评价准则和风险接受准则比较，输出依据风险评价准则按优先顺序排列的风险列表。风险识别和分析中得到的后果、可能性也宜被用于风险评价活动。需要注意的是多个中低风险的聚合可能导致更高的整体风险。注：见GB/T 31722-2015中8.3。6.4 风险处置对风险评估给出的具体风险，宜制定风险处置计划，并结合组织自身的业务要求和能力限制，选择风险处置策略。风险处置策略主要要包括以下类型：a） 风险降低：指为降低风险的可能性，减少风险负面结果所采取的行动。即对风险采取控制措施，减少威胁发生的可能性和带来的影响，使风险级别降低，残余风
31、险在重新评估后能够为组织风险策略接受。b） 风险规避：指不卷入风险处境的决定或撤离风险处境的行动。通过选择放弃某些可能引发风险的业务或资产、采用改变环境或取消风险相关活动等方式实现对风险的规避。c） 风险转移：指与另一方对风险带来的损失或收益的共享行为。即将风险全部或部分转移给其他方，组织可采用购买保险，与合作伙伴共同承担的方式对风险进行转移。d） 风险保留：指对来自特定风险的损失或收益的接受行为。在满足组织安全策略的情况下，对风险不采取任何控制措施，接受特定风险可能带来的损失。如果组织选择风险降低策略，则需针对风险列表中的风险选择第7章的ICT供应链安全风险控制措施执行，以保证控制措施执行后
32、，残余风险能够被组织所接受。注：见GB/T 31722-2015中第9章。6.5 风险监督和检查风险监督和检查的目的是确保组织的风险在可接受范围内。ICT供应链的风险是动态的。威胁、脆弱性、风险可能性、风险影响等均可能会随着组织业务的变化而改变。组织应设置风险监督和检查计划，监视风险管理活动，定期评审控制措施，及时调整范围边界。宜持续监督和检查以下事项：资产新增以及资产价值发生变更的情况；新增的威胁、脆弱性；已评估的威胁、脆弱性和风险因聚合导致的不可接受的风险；ICT供应链安全事件。注：见GB/T 31722-2015中第12章。6.6 风险沟通和记录风险沟通和记录是在风险管理者以及利益相关者
33、之间,通过交换、共享有关风险信息实现管理风险的活动。宜沟通和记录的内容包括但不限于： 利益相关者的关注点； ICT供应链背景信息； 供应商基本信息； 产品、服务的基本信息； 充分识别ICT供应链风险的方法； ICT供应链风险基本信息，包括供应链风险事件描述、风险评估结果等； ICT供应链风险处置措施、实施计划及效果等。注：见GB/T 31722-2015中第11章。7 ICT供应链安全风险控制措施7.1 控制措施应用原则本章列出了ICT供应链安全风险控制措施集合，需方或供应商宜针对组织的特点和识别的安全风险，选择、定制和实施供应链安全措施。基于ICT供应链风险管理过程，本标准推荐组织依据以下原
34、则选择供应链的安全控制措施：a） 组织的类型、战略、业务目标、客户需求；b） 组织架构和组织流程（安全方面、质量方面等）；c） 组织的安全策略和安全风险承受能力；d） 组织的ICT供应链的安全威胁、脆弱性；e） 相关的法律法规；f） 组织ICT供应链结构和语境；g） 组织的风险评估结果。7.2 技术安全措施7.2.1 物理与环境安全组织宜：a） 确保外部人员访问ICT供应链基础设施受控区域前得到授权或审批，由专人全程陪同，并登记备案；b） 及时更新供方对ICT供应链基础设施的物理访问权限；c） 评估系统集成商是否具有物理与环境安全策略，是否具有持续保证物理与环境安全的能力，并通过合同协议对系统
35、集成商的物理与环境安全进行要求；d） 具有备用的工作场所、通信线路和供应链管理信息系统，防止自然灾害或不可抗力的外因导致供应链中断。7.2.2 系统与通信安全组织宜：a) 具备边界保护机制，保护ICT供应链基础设施内的物理连接和逻辑连接。b) 定期开展ICT供应链基础设施边界安全脆弱性评估及抽样检查，并及时采取纠正措施；c) 如在ICT供应链基础设施中采用密码技术的，宜符合国家密码管理相关规定。d) 使用多个供应来源以提高通信系统组件可用性，减少ICT供应链基础设施受损害的影响；e) 宜确保供应链关键信息的传输安全，采取安全措施保证信息传输机密性。7.2.3 访问控制组织宜：a) 建立用户的账
36、户管理体系，包括用户注册、角色管理、权限和授权管理和身份鉴别等措施；b) 在系统集成商、供应商和外部服务提供商发生变更的情况下，更新访问权限等控制措施；c) 在信息系统及ICT供应链决策过程明确职责定位；d) 在职责定位的基础上，采取最小权限和授权机制；e) 监控、审核和记录从外部对ICT供应链基础设施相关的访问；f) 根据组织的信息安全策略制定访问控制协议要求，并对访问协议进行定期更新。如明确系统集成商和外部供应商对信息系统和ICT供应链基础设施的访问级别；g) 限制组织内设备在外部信息系统中的使用；h) 依据不同的访问级别，把ICT供应链基础设施的接口，选择性地提供给系统集成商、供应商和外
37、部服务提供商；i) 使用自动化方式实现账户管理，包括进行包括通知变更、禁用过期账户、自行审核高危操作和超时自动注销等；j) 从供应链角度，对组织与外部供应商互连的信息系统和操作任务进行核查和记录，包括了解与各类供方的组件/系统连接状况、共同开发和操作环境、共享的数据请求和检索事务等。7.2.4 标识与鉴别组织宜：a） 对组织供应链基础设施的系统或人员分配身份标识，对访问ICT供应链基础设施的用户（包括组织内部用户、外部供应商用户等）进行身份标识和鉴别。b） 管理ICT供应链基础设施内非组织用户的用户身份标识和认证的建立、审计、使用和撤销；c） 对交付前产品标识的改变提供相应的规则，使所交付的产
38、品在ICT供应链中可进行监管链验证；d） 对设备和组件分配产品标识，使用编码、条码、ID或者组织自定义的其他标识，包括：1) 对于软件开发，宜为已实现配置项识别的组件分配产品标识；2) 对于设备和操作系统，宜在其进入组织的ICT供应链框架时分配产品标识，例如通过运输、接收或下载完成时。7.2.5 供应链完整性保护组织宜：a) 对可能造成ICT供应链基础设施破坏的行为进行监控（如外部攻击或软件开发过程中植入的恶意代码）；b) 对信息系统和组件的完整性进行测试和验证（如使用数字签名或校验和机制），或使用有限权限环境（如沙箱）等；c) 确保实施代码认证机制，如数字签名，以确保ICT供应链框架和信息系
39、统的软件、固件和信息的完整性；d) 直接从经过验证的源获取二进制或机器可执行代码；e) 采取硬件完整性保护措施，如硬件拆箱保护；f) 验证集成商、供应商和外部服务提供商提供的篡改保护机制。7.2.6 可追溯性组织宜：a) 建立和维护可追溯性的策略和程序，记录和保留信息系统、组件或ICT供应链中产品和服务的原产地或原提供商的相关信息；b) 对于追溯源的改变，跟踪、记录并通知到有关供应链干系人；c) 确保追溯到对信息系统或ICT供应链中组件、工具、数据和过程有影响的个人；d) 确保可追溯信息和可追溯更改记录的抗抵赖性，包括时间、用户信息等；e) 建立可追溯基线，对组件、系统以及整个供应链进行记录、
40、监测和维护；并将可追溯基线嵌入供应链流程和相关信息系统；f) 使用多种可重复的方法跟踪追溯源的变更，包括变更的数量和频率，减少“开/关”过程和程序以及人为错误。例如，配置管理数据库可用于跟踪对软件模块、硬件组件和文档的更改。7.3 管理安全措施7.3.1 制度和人员管理7.3.1.1 管理制度组织宜：a） 制定供应链管理的总体方针和安全策略，说明供应链管理的总体目标、范围、原则和安全框架等。b） 对供应链建立安全管理制度，包含供应链生命周期中主要活动、ICT供应链基础设施和外部供应商管理等内容；c） 对要求供应链管理人员或操作人员执行的重要管理操作建立操作规程；d） 在供应商关系发生重大变化或
41、供应链发生重大安全事件时，对供应链安全管理制度进行检查和审定，对存在不足或需要改进的安全管理制度进行修订。7.3.1.2 管理机构组织宜：a） 明确供应链安全管理部门，负责指导和协调组织相关部门的供应链安全管理工作，并定义供应链安全管理职责；b） 提供用于供应链安全管理的资金、资产和权限等可用资源；7.3.1.2 人员管理组织宜：a） 制定针对涉及ICT供应链基础设施的人员的安全要求，包括管理者、员工和第三方人员等；b） 确保涉及ICT供应链各部门、各环节的责任人的可信度，可以满足对宜职位的安全要求。c） 及时终止离岗和调任人员对供应链基础设施的访问权限。包括： 采购和承包人员、项目经理、供应
42、链和物流人员、运输和接收人员； 信息技术人员、质量人员、组织高层管理人员、系统管理员、网络管理员、安全管理员。d） 明确划分管理和执行ICT供应链的人员职责定位，包括： 高级管理人员以及支撑ICT供应链的签约、物流、交付/接收、采购安全等职责定位； 供应链方案管理人员和负责完成方案的需方组织内部人员的职责定位； 覆盖系统生命周期的系统工程师或安全工程师，涉及需求定义、开发、测试、部署、维护、更新、更换、交付和接收、IT技术等职责定位。7.3.1.3 教育培训组织宜：a） 制定安全培训计划，将ICT供应链安全风险管理培训纳入安全培训计划中，并定期执行；b） 设立专人负责供应链安全培训工作，培训对
43、象宜包括所有参与供应链基础设施的组织内部人员和供应商人员或相关责任人；c） 培训内容可包括供应链安全相关的法律法规、标准规范、程序流程、应急处理等，培训内容需要根据安全形势变化和组织，进行不断更新。7.3.2 供应链生命周期安全7.3.2.1 配置管理组织宜：a） 明确供应链管理人员在配置管理中的职责定位，包括确定和协调组织不同部门间在配置管理中的目标、范围、角色、职责、义务和管理规范；b） 制定覆盖全生命周期的配置管理策略，包括定义在整个系统开发生命周期中的配置参数，定义信息系统的配置项并进行配置管理，考虑配置项的数据留存、追踪和元数据等；c） 与系统集成商、外部服务提供商等外部供应商协调配
44、置管理策略。d） 建立相应的实施配置管理控制程序，包括向产品或服务插入和删除组件的规程，制定主体配置操作手册，依据手册对设备进行安全访问、优化配置更改等工作。e） 将信息系统设置为仅提供基本功能，禁止或限制使用不必要的物理和逻辑端口、协议或服务，指定可以实现系统最少功能的组件，以减少ICT供应链受到攻击的风险；f） 对产品/服务和ICT供应链基础设施的变更进行安全影响分析，以确定是否需要采取额外的安全控制措施，影响分析人员宜包含系统工程师和安全工程师；g） 及时记录和保存系统的基本配置信息，包括网络拓扑结构、各个设备安装的软件组件、软件版本和补丁信息、各个设备或软件组件的配置参数等；e） 在组
45、织内部建立和维护配置管理基线，包括：1） 建立信息系统和ICT供应链基础设施的配置基线，并与系统集成商、外部服务提供商和供应商达成一致；2） 建立基线配置的规范，并可根据需要建立基线配置的开发及测试环境；3） 记录基线配置的变更和相关组织的通报、调整；4） 运行和维护基线配置的基本要求，通过基本要求保证供应链的基本安全条件；5） 定期审核和更新基线配置，实现基线变化的可追溯。f） 对配置访问进行安全控制，包括：1） 对配置更改相关的物理和逻辑访问控制进行定义、记录、批准和管理。2） 对配置的强制执行和自动访问进行审核和限制；3） 对签名组件的更改进行审核和限制，以确定组件使用组织认可和批准的数
46、字签名证书；4） 限制软件库驻留、查询、更改的权限，并定义特权程序和相应权限。5） 建立对非授权访问实施控制的技术能力和应急响应能力。g） 对ICT供应链基础设施的配置更改实施安全控制，监控审核配置设置中未授权的更改，包括：1） 根据职责定位，要求配置的所有者、授权管理者，对配置更改进行系统审核，以确定是否发生未经授权的更改；2） 明确配置可更改的类型、程序、批准和审计要求；3） 基于安全风险分析和组织策略，审核对信息系统配置的变更并决定是否批准；4） 经过审批后才可更改、安装经审核的配置组件或调整配置参数，操作过程宜保留不可更改的审计日志，操作结束后宜同步更新配置信息库，识别、记录所有的配置改变细节，包括与原有配置的差异和原因；5） 按照组织定义的时间，保留信息系统的配置更改记录；6） 建立未经授权的配置更改的应急响应和配置恢复能力；7） 审计和审核信息系统的配置控制变更相关活动；8） 提高管理、审核和控制配置更改的自动化程度。7.3.2.2 供应商开发要求ICT产品或服务的开发商和供应商宜：a) 具备软件开发管理制度，明确开发过程的控制方法、管理流程和人员行为准则；b) 制定代码安全规范，要求开发人员参照规范提升代码质量，例如：1） 使用最佳安全编码实践来避免常见的安全缺陷。2） 使用安全硬件设计实践（如适用）。3） 定期安排对相关人员的安全开发工程