导图社区 信息安全管理体系控制指南 27002_2022 部分带解析
- 51
- 举报
信息安全管理体系控制指南 27002_2022 部分带解析
信息安全管理体系控制指南 ISO/IEC 27002:2022，部分条款带解析，持续更新中，希望对你有所帮助！
编辑于2023-11-14 11:23:38- ISO/IEC 27002:2022
- 信息安全管理体系控制指南
- 相似推荐
- 大纲
信息安全管理体系控制指南 ISO/IEC 27002:2022
信息安全术语
1.访问控制access control： 确保基于业务和信息安全要求授权和限制对资产的物理和逻辑访问的方法。
2.资产asset： 任何对组织有价值的事物。 在信息安全环境中，可以区分两种资产： 1)主要资产： 一信息； 一业务流程和活动； 2)所有类型的支持资产（主要资产所依赖的），例如： 一硬件； 一软件； 一网络； 一工作人员； 一站点； 一组织结构。
3.攻击attack： 未授权的破坏、更改、禁用、访问资产的成功或不成功的尝试，或任何试图暴露、窃取或未经授权使用资产的行为。
4.鉴别authentication： 保证实体声称的特征属性是正确的。
5.真实性authenticity： 一个实体是它所声称的那样的属性。
6.监管链chain of custody： 从一个时间点到另一个时间点，材料的可证明的持有、移动、处理和定位 注释1：在ISO/IEC27002环境下，材料包括信息和其他相关资产。
7.机密消息confidential information： 不打算对未经授权的个人、实体或过程可用或向其披露的信息。
8.控制control：保持和/或改变风险的措施 注释1：控制包括但不限于任何过程、策略、设备、实践或其他保持和/或改变风险的条件和/或行动。 注释2：控制可能并不总是产生预期或假定的改变效果。
9.中断disruption： 一种事故，无论是预期的还是未预期的，都会导致产品和服务的预期交付相对于组织的目标发生计划外的负面偏离。
10.终端设备endpoint device： 联网的信通技术(ICT)硬件设备。 注释1：端点设备可以指台式计算机、笔记本电脑、智能手机、平板电脑、客户机、打印机或其他专用硬件，包括智能电表和物联网(IoT)设备。
11.实体entity： 与具有可识别的独特存在的领域的运营目的相关的项目。 注释1：一个实体应有一个物理或逻辑的具象化实例。例如个人、组织、设备、一组像这样罗列的事物、电信服务的个人订户、SIM卡、护照、网络接口卡、软件应用、服务或网站 等。
12.信息处理设施information processing facility： 任何信息处理系统、服务或基础设施，或容纳信息的物理位置。
13.信息安全的违背/破坏information security breach： 危及信息安全，导致传输、存储或以其他方式处理的受保护信息遭到意外破坏、丢失、篡改、泄露或访问。
14.信息安全事件information security event： 表明可能发生信息安全的破坏或控制失败的事件。
15.信息安全事故information security incident： 一个或多个相关且已确定的信息安全事件，可能会损害组织的资产或干扰其运营。
16.信息安全事故管理information security incident management： 采用一贯的、有效的方法处理信息安全事故
17.信息系统information system： 一组应用程序、服务、信息技术资产或其他信息处理部件。
18.利益相关方interested party/stakeholder： 能够影响决策或活动、被决策或活动影响或认为自己受决策或活动影响的个人或组织。
19.不可否认性non-repudiation： 证明声称的事件或行动及其发起实体发生的能力
20.工作人员personnel： 在组织的指导下工作的人员 注释1：工作人员的概念包括组织的成员，如理事机构、最高管理层、雇员、临时工作人员、承包商和志愿者。
3.1.21个人可识别信息personally identifiable information/Pll (a)可用于在信息和与信息相关的自然人之间建立联系的任何信息，或 (b)直接或间接与自然人相关联的任何信息。 条目注释1：定义中的"自然人"是指P主体(3.1.22)。要确定P主体是否可识别，应考虑 持有数据的隐私利益相关方或任何其他方可以合理使用的所有方法，以建立Pll集和自然人之 间的联系。
22.Pll主体Pll principal： 与PII个人可识别信息相关的自然人。 注释1：根据司法管辖区和特定的数据保护和隐私立法，也可以使用同义词"数据主体"代替术语"P主体"。
23.Pll处理者Pll processor： 代表PII控制者并根据其指示处理PII个人可识别信息的隐私利益相关方。
24.策略policy: 由最高管理者正式表达的组织的意图和方向。
25.隐私影响评估privacy impact assessment： 识别、分析、评估、咨询、沟通和规划处理PII个人可识别信息的潜在隐私影响的整体流程，在组织更广泛的风险管理框架内制定。
26.程序procedure： 开展活动或过程的特定方式。
27.过程process： 使用或转换输入以交付结果的一组相互关联或相互作用的活动。
28.记录record： 组织或个人在履行法律义务或业务交易中，被作为证据、同时也作为资产创建、接收和维护的信息。 注释1：此处的法律义务包括所有法律、法规、监管和合同要求。
29.恢复点目标recovery point objective/RPO： 发生中断后数据将要恢复到的时间点。
30.恢复时间目标recovery time objective/RTO 发生中断后，服务和/或产品以及支持系统、应用程序或功能恢复到最低水平所历经的时长。
31.可靠性reliability 与预期行为和结果一致的特性。
32.规则rule： 被接受的原则或指示，说明组织要求做什么、允许什么或不允许什么。 注释1：规则可以在专题策略和其他类型的文件中正式表述。
33.敏感信息sensitive information： 由于对个人、组织、国家安全或公共安全的潜在不利影响，需要防止其不可用、未经授权的访问、修改或公开披露的信息。
34.威胁threat： 可能对系统或组织造成损害的意外事故的潜在原因。
35.专题策略： 由适当层级的管理者正式表达的，关于特定对象或主题的意图和方向。 注释1：专题策略可以正式表达规则或组织标准。 注释2：一些组织对这些专题策略使用其他术语。 注释3：文档中提及的专题策略与信息安全相关。关于访问控制的专题策略示例,关于桌面清理和屏慕清理的专题策略。
36.用户user： 有权访问组织信息系统的相关方。 比如工作人员、客户、供应商。
37.用户终端设备user endpoint device： 用户用来访问信息处理服务的终端设备。 注释1：用户终端设备可以指台式计算机、笔记本计算机、智能电话、平板电脑、客户机等。
38.脆弱性vulnerability 可能被一个或多个威胁利用的资产或控制的弱点。
主题和属性
控制分类被称为主题
人，如果涉及个人；
物理的，如果涉及物理对象；
技术，如果涉及技术；
否则，被归类为组织。
控制类型：用于从是何时以及如何改变风险的角度来认识控制
预防性：旨在防止信息安全事件发生的控制措施；
检测性：信息安全事件发生时起作用的控制措施；
纠正性：信息安全事件发生后起作用的控制措施。
信息安全特性
机密性
指网络信息不泄露给非授权的用户、实体或程序，能够防止非授权者获取信息。这些信息不仅包括国家机密，也包括企业和社会团体的商业机密和工作机密，还包括个人信息。例如，网络信息系统上传递口令敏感信息，若一旦攻击者通过监听手段获取到，就有可能危及网络系统的整体安全。人们在应用网络时很自然地要求网络能提供保密性服务，而被保密的信息既包括在网络中传输的信息，也包括存储在计算机系统中的信息。就像电话可以被窃听一样，网络传输信息也可以被窃听，解决的办法就是对传输信息进行加密处理。存储信息的机密性主要通过访问控制来实现，不同用户对不同数据拥有不同的权限。 维护信息机密性的措施包括： ·Encryption加密 ·Password密码 ·Two-factor authentication两因素验证 ·Biometric生物识别 ·Security tokens安全令牌
完整性
指网络信息或系统未经授权不能进行改变的特性。即信息在存储或传输过程中保持不被修改、不被破坏和丢失的特性。数据的完整性是指保证计算机系统上的数据和信息处于一种完整和未受损害的状态，这就是说数据不会因为有意或无意的事件而被改变或丢失。除了数据本身不能被破坏外，数据的完整性还要求数据的来源具有正确性和可信性，也就是说需要首先验证数据是真实可信的，然后再验证数据是否被破坏。影响数据完整性的主要因素是人为的蓄意破坏，也包括设备的故障和自然灾害等因素对数据造成的破坏。 维护信息完整性的措施包括： ·Encryption加密 ·Hashing散列 ·User access controls用户访问控制 ·Checksums校验和 ·Version control版本控制 ·Backups备份
可用性
指合法许可的用户能够及时获取网络信息或服务的特征，即可授权实体或用户访问并按要求使用信息的特性。简单地说，就是保证信息在需要时能为授权者所用，防止由于主客观因素造成的系统拒绝服务。例如，网站能够给用户提供正常的网页访问服务，防止拒绝服务攻击。 减轻可用性威胁的措施包括 ·Off-site backups 异地备份 ·Disaster recovery 灾难恢复 ·Redundancy 冗余 ·Failover 故障转移 RAID 袭击 ·High-availability clusters 高可用性集群
网络安全概念
识别
保护
检测
响应
恢复
运营能力
从业者从信息安全能力的角度来认识控制的属性，共15条
治理、资产管理、信息保护、人力资源安全、物理安全、系统和网络安全、应用安 全、安全配置、身份和访问管理、威胁和漏洞管理、连续性、供应商关系安全、法律与 合规性、信息安全事件管理和信息安全保证
安全域
治理与生态系统
包括"信息系统安全治理&风险管理"和"生态系统网络安全管理"(包括内部和外部利益相关者)；
保护
包括"IT安全架构"、"IT安全管理"、"身份和访问管理"、"IT安全维护"和"物理和环境安全"；
防御
包括"检测"和"计算机安全事件管理"；
韧性
包括"业务连续性"和"危机管理"。
5组织控制
5.1信息安全策略
控制 应定义信息安全策略和专题策略，由管理层批准，发布，传达给相关人员和利益相关方并得到他们的认可，并在计划的时间间隔和发生重大变化时进行审查。
目的 根据业务、法律、法规、监管和合同要求，确保管理方向和信息安全支持的持续适用性、充分性和有效性。
指南
在最高级别，组织应定义由最高管理层批准的"信息安全策略"，该策略规定了组织管理其信息安全的方法。
信息安全策略应顾及来自以下方面的要求： a)业务战略和要求； b)法规、立法和合同； c)当前和预计的信息安全风险和威胁。
信息安全策略应包含关于以下方面的声明： a)信息安全的定义； b)信息安全目标或设定信息安全目标的框架； c)指导所有信息安全相关活动的原则； d)承诺满足与信息安全相关的适用要求； e)致力于信息安全管理体系的持续改进； f)将信息安全管理的职责指派给规定的角色； g)处理豁免和例外的程序。 应根据相关人员的适当权限和技术能力，指派制定、评审和批准专题策略的责任。 评审应包括评估改进组织信息安全策略和专题策略的机会，并管理信息安全以应对以下变化： a)组织的业务战略； b)组织的技术环境； c)法规、法令、法律和合同； d)信息安全风险； e)当前和预计的信息安全威胁环境； f)从信息安全事件和事故中吸取的教训。 信息安全策略和专题策略的评审应考虑管理评审和审计的结果。当一项策略发生变化时，应考虑对其他相关策略进行评审和更新，以保持一致性。
5.2信息安全角色和职责
控制 应根据组织需求定义和分配信息安全角色和职责。
目的 为组织内信息安全的实施、运营和管理建立一个定义明确、得到批准和理解的结构。
指南
应根据信息安全策略和专题策略分配信息安全角色和职责（参见5.1）。组织应当定义和管理以下方面的职责： a)保护信息和其他相关资产； b)执行特定的信息安全流程； c)信息安全风险管理活动，特别是对残余风险的接受（例如对风险所有人）。 d)使用组织信息和其他相关资产的所有人员。 必要时，应对这些职责进行补充，为特定站点和信息处理设施提供更详细的指导。被分配了信息安全职责的个人可以将安全任务指派给其他人，但是他们仍须担责，并且应该确定任何委派的任务都已正确执行。 应定义、记录和沟通个人负责的每个安全领域。应该定义和记录授权级别。担任特定信息安全角色的个人应具备该角色所需的知识和技能，并应得到支持以跟上与该角色相关的发展，以及履行该角色职责所需的发展。
许多组织任命一名信息安全管理人员，全面负责信息安全的开发和实施，并支持风险识别和缓解控制措施。 然而，配置资源和实施控制的责任通常由各个管理人员分别承担。一种常见的做法是为每项资产指定一名所有者，由其负责该资产的日常保护。 根据组织的规模和资源配置，信息安全可以由除现有角色之外的专门角色或职责来负责。
5.3职责分离
控制 相互冲突的职责和相互冲突的责任领域应该被分离。
目的 降低欺诈、出错和绕过信息安全控制的风险。
指南
职责和责任领域的分离旨在分离不同个人之间的职责冲突，以防止一个人独自执行潜在冲突的职责。 组织应该确定哪些职责和责任范围需要分离。以下是可能需要隔离的活动示例： a)发起、批准和执行变更； b)请求、批准和实施访问权限； c)设计、实施和审查代码； d)开发软件和管理生产系统； e)使用和管理应用程序； f)使用应用程序和管理数据库； g)设计、审计和确保信息安全控制。
在设计隔离控制时，应考虑共谋的可能性。小型组织可能会发现职责分离很难实现，但应尽可能和切实可行地应用这一原则。当难以分离时，应考虑其他控制措施，如活动监控、审计跟踪和管理监督。 使用基于角色的访问控制系统时应小心谨慎，以确保人员不会被授予冲突的角色。当组织有大量的角色时，应该考虑使用自动化工具来识别冲突并促进冲突的消除。应该仔细定义和设置角色，以便在删除或重新分配角色时最大限度减少权限问题。
5.4管理层责任
控制 管理层应要求所有人员根据组织的既定信息安全策略、专题策略和程序来应用信息 安全。
目的 确保管理层了解其在信息安全中的角色，并采取措施确保所有人员了解并履行其信 息安全职责。
指南
管理层应对信息安全策略、专题策略、程序和信息安全控制措施提供可证实的支持。
管理层责任应包括确保人员： a)在被授权访问组织的信息和其他相关资产之前，已正确了解其信息安全角色和职责； b)获得了指南，规定了他们在组织内的角色的信息安全要求； c)被授权履行组织的信息安全策略和专题策略； d)信息安全意识达到与其在组织内的角色和职责相匹配的水平； e)遵守雇佣、合同或协议的条款和条件，包括组织的信息安全策略和适当的工作方法； f)通过专业继续教育持续拥有适当的信息安全技能和资格； g)在可行的情况下，为报告违反信息安全策略、专题信息安全策略或程序的行为("举报")提供保密渠道。这可以是允许匿名举报，或者有预置措施确保只有需要处理此类举报的人才知晓举报人身份； h)为实施组织的安全相关流程和控制提供充足的资源和项目规划时间。
5.5与职能机构的联系
控制 组织应当与相关职能机构建立并保持联系。
目的 确保组织与相关法律、监管和监督机构之间在信息安全方面有适当的信息沟通。
指南
组织应指定何时联系职能部门（如执法机关、监管部门、监督机构）以及由谁联系，以及如何及时报告已发现的信息安全事件。 还应利用与职能机构的联系来促进对这些职能机构当前和未来的期望的理解（例如适用的信息安全法规)。
受到攻击的组织可以请求职能机构对攻击源采取行动。 维护此类联系可能是支持信息安全事件管理或应急计划和业务连续性流程的一项要求。与监管机构的联系也有助于预测和准备影响组织的相关法律或法规即将发生的变化。 与其他机构的联系包括公用事业、应急服务、电力供应商以及健康和安全部门【如消防部门（与业务连续性相关）、电信提供商（与线路路由和可用性相关）和水供应商（与设备冷却设施相关）】。
5.6与特定相关方的联系
控制 组织应与特定相关方或其他专业安全论坛、专业协会建立并保持联系。
目的 确保在信息安全方面有适当的信息沟通。
指南
应把特定的相关方或论坛中的成员关系视作一种手段，用来： a)增进对最佳实践的了解，并掌握最新的相关安全信息:A R b)确保对信息安全环境的了解是最新的； c)接收与攻击和漏洞相关的预警、建议和补丁； d)获得专家信息安全建议； e)分享和交流有关新技术、产品、服务、威胁或漏洞的信息； f)在处理信息安全事件时提供合适的联系人。
5.7威胁情报
控制 应收集并分析与信息安全威胁相关的信息，以产生威胁情报。
目的 提供组织威胁环境的意识，以便采取适当的缓解措施。
指南
威胁情报可分为三个层次： a)战略威胁情报：交换关于不断变化的威胁形势的高级别信息（例如攻击者的类型或攻击的类型)； b)战术威胁情报：关于攻击者方法、工具和相关技术的信息； c)作战威胁情报：关于特定攻击的详细信息，包括技术指标。 以上三个层次的威胁情报都应该被顾及。
威胁情报应该是： a)相关的（即与保护本组织相关）； b)有洞察力的（即向组织提供对威胁形势的准确而详细的了解）； c)上下文的，提供情境意识（即根据事件发生的时间、地点、以前的经验和在类似组织中的流行程度为信息添加上下文)； d)可操作的（即组织可以快速有效地对信息采取行动）。
威胁情报活动应包括： a)建立生产威胁情报的目标； b)确定、审查和选择必要和适当的内部和外部信息来源，以提供生产威胁情报所需的信息； c)从选定的内部和外部来源收集信息； d)处理收集的信息，为分析做准备（例如翻译、格式化或确证信息）； e)分析信息，了解它与组织的关系以及对组织的意义； f)以可理解的形式与相关个人交流和分享。
应对威胁情报进行分析，并在以后使用： a)通过实施流程，将从威胁情报来源收集的信息纳入组织的信息安全风险管理流程； b)作为防火墙、入侵检测系统或反恶意软件解决方案等技术预防和检测控制的附加输入； c)作为信息安全测试流程和技术的输入。 组织应在互利合作的基础上与其他组织共享威胁情报，以改进整体威胁情报。 组织可以使用威胁情报来预防、检测或响应威胁。组织可以生成威胁情报，但更常见的是接收和利用其他来源生成的威胁情报。
5.8项目管理中的信息安全
控制 项目管理中应纳入信息安全。
目的 贯穿整个项目生命周期，确保在项目管理中有效解决与项目和可交付成果相关的信息安全风险。
指南
应将信息安全集成到项目管理中，以确保信息安全风险作为项目管理的一部分得到解决。这可适用于任何类型的项目，无论其复杂程度、规模、持续时间、学科或应用领域如何（如核心业务流程、T、设施管理或其他支持流程的项目）。
正在执行的项目管理中应要求： a)在整个项目生命周期中，信息安全风险作为项目风险的一部分，在早期阶段定期得到评估和处理； b)信息安全要求[如应用安全要求、遵守知识产权的要求等。]在项目的早期阶段得到解决； c)在整个项目生命周期中，考虑和处理与项目执行相关的信息安全风险，如内部和外部通信方面的安全； d)审查信息安全风险处理的进展，并评估和测试处理的有效性。 应由合适的人员或治理机构（如项目指导委员会）在预定义的阶段持续核查信息安全考虑因素和活动的适当性。 应定义与项目相关的信息安全责任和权限，并分配给指定的角色。
应该为所有类型的项目确定信息安全要求，而不仅仅是ICT开发项目。确定这些要求时，还应顾及以下因素： a)涉及哪些信息（信息判定），对应的信息安全需求有哪些（分类；）以及缺乏足够的安全性可能导致的潜在负面业务影响。 b)所涉信息和其他相关资产的必要保护需求，特别是在机密性、完整性和可用性方面； c)为了得出身份鉴别要求，对所声称的实体身份所需的信任或保证级别； d)为客户和其他潜在业务用户以及特权或技术用户（如相关项目成员、潜在运营人员或外部供应商)提供访问和授权流程； e)告知用户他们的义务和责任； f)源自业务流程的需求，如交易记录和监控、不可否认性需求； g)其他信息安全控制措施规定的要求（如记录和监控或数据泄漏检测系统的接口)； h)遵守组织运作的法律、法规、规章和合同环境； i)第三方满足组织的信息安全策略和专题策略（包括任何协议或合同中的相关安全条款)所需的信心或保证级别。
5.9信息和其他相关资产的清单
控制 应开发和维护信息和其他相关资产（包括所有者）的清单。
目的 识别组织的信息和其他相关资产，以保护其信息安全并分配适当的所有权。
指南
清单 1.组织应确定其信息和其他相关资产，并确定它们在信息安全方面的重要性。文件应酌情保存在专用或现有的清单中。 2.信息和其他相关资产的清单应准确、最新、一致，并与其他清单保持一致。确保信息和其他相关资产清单准确性的选项包括： a)根据资产清单定期审查已识别的信息和其他相关资产； b)在安装、更改或删除资产的过程中自动执行清单更新。 资产的位置应适当地包括在清单中。 清单不必是信息和其他相关资产的单一列表。考虑到清单应由相关职能部门维护，因此可将其视为一组动态清单，如信息资产、硬件、软件、虚拟机、设施、人员、能力、功能和记录的清单。 3.应根据与资产相关的信息分类对每项资产进行分类。信息和其他相关资产清单的粒度应符合组织的需求。
所有权 对于已识别的信息和其他相关资产，资产的所有权应分配给个人或团体，并应识别其分类(参见5.12、5.13)。应实施确保及时分配资产所有权的流程。当创建资产或将资产转移到组织时，应分配所有权。当当前资产所有者离开或改变工作角色时，应根据需要重新分配资产所有权。
所有者职责 资产所有者应负责在整个资产生命周期内对资产进行适当管理，确保： a)对信息和其他相关资产进行编目； b)信息和其他相关资产得到适当的分类和保护； c)定期审查分类； d)列出并链接支持技术资产的组件，如数据库、存储、软件组件和子组件； e)建立了信息和其他相关资产的可接受的使用要求（参见5.10）； f)访问限制符合分类，并且是有效的，并定期审查； g)删除或处置信息和其他相关资产时，以安全的方式进行处理，并从清单中删除； h)他们参与识别和管理与其资产相关的风险； i)他们支持承担管理其信息的角色和责任的人员。
1.信息和其他相关资产的清单通常是确保有效保护信息所必需的，也可能出于其他目的，如健康和安全、保险或财务原因。信息和其他相关资产的清单还支持风险管理、审计活动、漏洞管理、事件响应和恢复计划。 2.任务和责任可以委派（例如，委派给负责日常资产的保管人），但委派的人或团队仍然有责任。
5.10信息和其他相关资产的可接受的使用
控制 应确定、记录和实施处理信息和其他相关资产的可接受的使用规则和程序。
目的 确保信息和其他相关资产得到适当的保护、使用和处理。
指南
对使用或有权访问组织信息和其他相关资产的所有人员，包括外部用户，应令其知晓保护和处理组织信息和其他相关资产的信息安全要求。他们应对自己使用的任何信息处理设施负责。
组织应就信息和其他相关资产的可接受的使用建立专题策略，并将其传达给使用或处理信息和其他相关资产的任何人。关于可接受的使用的专题策略应该为个人如何使用信息和其他相关资产提供明确的指南。专题策略应说明： a)从信息安全的角度看，个人的期望的和不可接受的行为； b)对信息和其他相关资产的允许或禁止使用； c)组织实施的监控活动。
应根据信息的分类（参见5.12）和确定的风险，为整个信息生命周期制定可接受的使用程序。应顾及以下事项： a)支持每个分类级别的保护要求的访问限制； b)维护信息和其他相关资产的授权用户记录； c)对信息的临时或永久拷贝的保护水平与对原始信息的保护水平一致； d)根据制造商的规范存储与信息相关的资产（参见7.8）； e)清晰标记存储介质（电子或物理）的所有副本，以引起授权接收者的注意（参见7.10)； f)作废信息和其他相关资产的授权以及支持的删除方法（参见8.10）。
可能出现相关资产不直接属于组织的情况，例如公共云服务。此类第三方资产以及与此类外部资产（如信息、软件）相关联的任何组织资产的使用应被确定为适用并受到控制，例如通过与云服务提供商签订协议。当使用协作工作环境时，也应该谨慎。
5.11资产返还
控制 员工和其他相关方在变更或终止其雇佣关系、合同或协议时，应归还其拥有的所有 组织资产。
目的 在变更或终止雇佣关系、合同或协议的过程中保护组织的资产。
指南
1.应正式发布雇佣变更或终止流程，以包括归还本组织拥有或委托给本组织的所有先前发放的实物和电子资产。 2.如果相关人员和其他相关方买下组织的设备或原本是使用他们自己的个人设备，应遵循相应的程序，确保所有相关信息被追溯并转移到组织，并从设备中安全地删除（参见7.14)。 3.如果相关人员和其他相关方掌握对继续运行至关重要的知识，该信息应形成文件并传递给组织。 4.在通知期间及之后，组织应防止收到雇佣终止通知的人员未经授权复制相关信息(例如知识产权)。
组织应明确标识和记录要归还的所有信息和其他相关资产，其中可能包括： a)用户终端设备； b)便携式存储设备； c)专业设备； d)信息系统、站点和物理档案的身份鉴别硬件（例如机械钥匙、物理令牌和智能卡)； e)信息的物理副本。
如果信息存在于不归组织所拥有的资产中，将很难索回。在这种情况下，有必要使用其他信息安全控制措施来限制信息的使用，如访问权限管理(5.18)或加密技术的使用(8.24)。
5.12信息分类
控制 应根据组织的信息安全需求，基于机密性、完整性、可用性和利益相关方的要求， 对信息进行分类。
目的 根据信息对组织的重要性，确保识别和理解信息的保护需求。
指南
1.组织应建立关于信息分类的专题策略，并将其传达给所有利益相关方。 组织应当考虑分类方案中的机密性、完整性和可用性要求。 信息的分类和相关保护控制措施应考虑共享或限制信息、保护信息完整性和确保可用性的业务需求，以及有关信息机密性、完整性或可用性的法律要求。除了信息之外的资产也可以按照其存储的、处理的或者掌控或保护的信息的分类来分类。 2.信息的所有者应对其分类负责。 分类方案应包括分类惯例和随着时间的推移对分类进行审查的标准。分类结果应根据信息在其生命周期中的价值、敏感性和重要性的变化进行更新。 该方案应符合关于访问控制的专题策略（参见5.1），并应能够满足组织的特定业务需求。
分类可以根据信息泄露对组织的影响程度来确定。方案中定义的每个级别都应该有一个在分类方案应用环境中有意义的名称。 分类方案应该在整个组织中保持一致，并包含在其程序中，以便每个人都以相同的方式对信息和适用的其他相关资产进行分类。通过这种方式，每个人都对保护要求有共同的理解，并应用适当的保护。
分类为处理信息的人提供了如何处理和保护信息的简明指示。创建具有相似保护需求的信息集合并指定适用于每个集合中所有信息的信息安全程序有助于实现这一点。这种方法减少了逐一进行风险评估和定制控制设计的需要。 例如，信息机密性分类方案可以基于以下四个级别，如下所示： a)泄露不会造成伤害； b)泄露会造成轻微的声誉损害或轻微的运营影响； c)泄露对运营或业务目标有重大的短期影响； d)泄露会对长期业务目标产生严重影响，或使组织的生存面临风险。
5.13信息标签
控制 应当根据组织采用的信息分类方案，制定并实施一套适当的信息标签程序。
目的 促进信息分类的交流，支持信息处理和管理的自动化。
指南
1.信息标签程序应涵盖所有格式的信息和其他相关资产。标签应反映5.12中建立的分类方案。标签应容易辨识。考虑到如何根据存储介质的类型访问信息或处理资产，这些程序应就标签的粘贴位置和方式提供指南。这些程序可以定义： a)省略标记的情况（例如略过标记非机密信息以减少工作量）； b)如何标记通过电子或物理方式或任何其他格式发送或存储的信息； c)如何处理无法标签的情况（例如，由于技术限制）。 标签技术的例子包括： a)物理标签； b)页眉和页脚； c)元数据； d)水印； e)橡皮图章。 2.数字信息应利用元数据来识别、管理和控制信息，特别是在机密性方面。元数据还应支持高效和正确的信息搜索，便于系统根据相关的分类标签进行交互和决策。 这些程序应说明如何根据组织的信息模型和ICT架构，将元数据附加到信息上，使用什么标签，以及如何处理数据。 系统在处理信息时，应根据信息的安全属性添加额外的相关元数据。 2.应使员工和其他相关方了解标签程序。应向所有人员提供必要的培训，以确保正确标记信息并进行相应的处理。 包含敏感或关键信息的系统的输出应带有适当的分类标签。
分类信息的标签是信息共享的一个关键要求。 可以附加到信息的其他有效元数据是：哪个组织过程、在什么时间创建了该信息。 信息和其他相关资产的标签有时会产生负面影响。恶意人员可以更容易地识别机密资产从而更容易导致潜在的滥用。 有些系统不在单个文件或数据库记录上标注它们的分类，而是以包含或允许包含的任何信息的最高分类级别来保护所有信息。在这种系统中，通常在导出信息时确定并标记信息。
5.14信息传递
控制 组织内部以及组织与其他方之间所有类型的信息传递设施都应当有信息传递的规 则、程序或协议。
目的 维护在组织内部以及与任何外部相关方之间传输的信息的安全性。
指南
常规 组织应当建立并向所有相关方传达关于信息传递的专题策略。保护传输中的信息的规则、程序和协议应反映所涉信息的分类。当信息在组织和第三方之间传递时，应建立并维护传递协议（包括接收方身份鉴别），以保护传递的所有形式的信息（参见5.10)。 信息传递可以通过电子传递、物理存储介质传递和口头传递来进行。 对于所有类型的信息传递，规则、程序和协议应包括： a)旨在保护被传递的信息免遭拦截、未经授权访问、复制、修改、错误路由、破坏和拒绝服务的控制措施，包括与所涉及信息的分类相称的访问控制级别，以及保护敏感信息所需的任何特殊控制措施，如使用加密技术（参见8.24）。 b)确保可追溯性和不可否认性的控制措施，包括维护信息在传递过程中的保管链； c)确定与传递相关的适当联系人，包括信息所有人、风险所有人、安全官和信息保管人（如适用）； d)发生信息安全事故（如物理存储介质或数据丢失）时的责任和义务； e)对敏感或关键信息使用商定的标签系统，确保标签的含义立即被理解，信息得到适当保护（参见5.13）； f)传递服务的可靠性和可用性； g)关于信息传递设施的可接受使用的专题策略或指南（参见5.10）； h)所有业务记录（包括邮件）的保留和作废指南； 注意：关于业务记录保留和处置，可能存在地方性法律法规。 i)顾及与信息传递相关的任何其他相关法律、法规、监管和合同要求（参见5.31、5.32、5.33、5.34)(如电子签名要求)。
电子传递 在使用电子通信设施进行信息传递时，规则、程序和协议还应顾及以下事项： a)检测和防范可能通过使用电子通信传播的恶意软件（参见8.7）； b)保护以附件形式传递的敏感电子信息； c)防止在通信中将文件和消息发送到错误的地址或号码； d)在使用即时消息、社交网络、文件共享或云存储等外部公共服务之前获得批准； e)通过可公开访问的网络传递信息时，身份鉴别级别应更高； f)与电子通信设施相关的限制（例如，防止自动将电子邮件转发到外部邮件地址)； g)建议员工和其他相关方不要发送包含重要信息的短消息服务(SMS)或即时消息，因为这些信息可能会在公共场所被读取（因此会被未授权人员读取）或存储在未受到充分保护的设备中； h)向员工和其他相关方警示使用传真机或服务的问题，包括： 1)未经授权访问设备内置存储以检索消息； 2)有意或无意地对机器进行编程，以向特定号码发送消息。
物理存储介质传递 当传递物理存储介质（包括纸张）时，规则、程序和协议还应包括： a)控制和通知传输、发送和接收的职责； b)确保消息的正确寻址和传输； c)包装应能保护内容物免受运输过程中可能出现的任何物理损坏，并符合任何制造商的规范，例如保护内容物免受任何可能降低储存介质恢复效果的环境因素的影响，如暴露于热、潮湿或电磁场中；使用包装和运输的最低技术标准（例如使用不透明的信封)； d)管理层批准的授权可靠快递员名单； e)快递员标识标准； f)根据要运输的存储介质中的信息的分类级别，使用拆封易察或有防拆封控制的装置（如袋子、容器）； g)核实快递员身份的程序； h)根据信息分类提供运输或快递服务的第三方的核准名单； i)保留日志，用于识别存储介质的内容、所应用的保护，以及记录授权接收者的列表、向转运保管人传递以及在目的地接收的时间。
口头传递 为保护信息的口头传递，应提醒员工和其他相关方： a)不要在公共场所或通过不安全的通信渠道进行机密的口头交谈，因为这些可能会被未经授权的人偷听； b)不要将包含机密信息的信息留在应答机或语音信息中，因为这些信息可能被未经授权的人重播、在公共系统中存储、或因误拨而导致不当的存储； c)筛选合适级别的人员去听对话； d)确保实施适当的房间控制（例如隔音、关门）； e)任何敏感对话应以免责声明作为开始，让在场的人知道他们将要听到的内容的保密级别和任何处理要求。
5.15访问控制
控制 应根据业务和信息安全要求建立和实施控制规则，控制对信息和其他相关资产的物 理和逻辑访问。
目的 确保授权访问，防止未经授权访问信息和其他相关资产。
指南
信息和其他相关资产的所有者应确定与访问控制相关的信息安全和业务要求。应定义关于访问控制的专题策略，该策略应考虑这些要求，并应传达给所有相关利益方。 这些要求和专题策略应顾及以下几点： a)确定哪些实体需要对信息和其他相关资产的哪种类型的访问； b)应用程序的安全性（参见8.26）； c)物理访问，由适当的物理入口控制来支持（参见7.2、7.3、7.4）； d)信息传播和授权（如“按需知晓”原则）以及信息安全级别和信息分类（参见5.10、5.12、5.13); e)对特权访问的限制（参见8.2）； f)职责分离（参见5.3）； g)关于限制访问数据或服务的相关法律、法规和任何合同义务（参见5.31、5.32、5.33、5.34、8.3); h)访问控制功能的分离（如访问请求、访问授权、访问管理）； i)访问请求的正式授权（参见5.16和5.18）； j)访问权限的管理（参见5.18）； k)记录（参见8.15）。
应定义适当的访问权限和限制，并通过将其映射到相关实体来实施访问控制规则(参见5.16)。实体可以是人类用户以及技术或逻辑项目（例如，机器、设备或服务)。为了简化访问控制管理，可以为实体的分组分配特定的角色。 在定义和实施访问控制规则时，应顾及以下因素： a)访问权限和信息分类之间的一致性； b)访问权限与物理周界安全需求和要求之间的一致性； c)考虑分布式环境中所有类型的可用连接，从而仅向实体提供对它们被授权使用的信息和其他相关资产（包括网络和网络服务）的访问； d)考虑如何反映与动态访问控制相关的元素或因素。
1.在访问控制的上下文中，通常会用到一些支配性的原则。两个最常用的原则是： a)按需知晓：一个实体只被授权访问该实体执行其任务所需的信息（不同的任务或角色意味着不同的必需信息，因此有不同的访问权限)； b)按需使用：一个实体只有在存在明确需求的情况下才被分配访问信息技术基础设施的权限。 2.在指定访问控制规则时，应注意顾及： a)以最小特权为前提建立规则，“未经明确允许，则一律禁止”，而不是更弱的规则“未经明确禁止，一律允许”； b)由信息处理设施自动发起和由用户自行决定发起的信息标签的变化（参见5.13); c)由信息系统自动发起和由管理员发起的用户权限变更； d)何时定义规则和定期审查对规则的批准。 3.访问控制规则应由书面程序（参见5.16、5.17、5.18、8.2、8.3、8.4、8.5、8.18)和规定的职责（参见5.2、5.17）支持。 实现访问控制有多种方式，如MAC(强制访问控制)、DAC(自主访问控制)、RBAC(基于角色的访问控制)和ABAC(基于属性的访问控制)。
访问控制规则还可以包含动态元素（例如将之前的访问或特定环境属性值作为变量的函数)。访问控制规则可以以不同的粒度实施，从覆盖整个网络或系统到特定的数据字段，还可以考虑用户位置或用于访问的网络连接类型等属性。这些原则以及如何定义访问控制粒度会对成本产生重大影响。更强的规则和更多的粒度通常会导致更高的成本。应根据业务需求和风险因素来定义应用哪些访问控制规则以及需要哪些粒度。
5.16身份管理
控制 应该管理身份的整个生命周期。
目的 对访问组织信息和其他相关资产的个人和系统进行唯一标识，并适当分配访问权 限。
指南
身份管理环境中使用的流程应确保： a)对于分配给个人的身份，特定身份仅与单一的个人相关联，以便能够让该人对使用该特定身份执行的行为负责； b)分配给多人的身份（如共享身份）仅在出于业务或运营原因有必要时才允许，并需经过专门的批准和记录。 c)分配给非人类实体的身份要经过适当的分离的批准和独立的持续监督； d)如果不再需要，则应及时禁用或移除身份（例如，如果与身份相关联的实体被删除或不再使用，或者如果与身份相关联的人已经离开组织或改变了角色)； e)在特定范围内，单个身份被映射到单个实体[即避免多个身份映射到同一上下文中的同一实体（重复身份)]； f)所有关于使用和管理用户身份和鉴别信息的重要事件的记录都得到保留。 组织应该有一个支持流程来处理与用户身份相关的信息更改。这些过程可以包括重新验证与个人相关的可信文档。
当使用由第三方提供或颁发的身份（例如社交媒体凭据)时，组织应确保第三方身份提供所需的信任级别，并且任何相关风险都是已知的并得到了充分的处理。这可以包括与第三方相关的控制（参见5.19)以及与相关鉴别信息相关的控制（参见5.17)。
提供或撤销对信息和其他相关资产的访问通常是一个多步骤的过程：： a)确认待建立身份的业务要求； b)在给实体分配逻辑身份之前验证实体的身份； c) 建立身份； d) 配置和激活身份。这还包括相关身份鉴别服务的配置和初始设置； e)根据适当的授权或权利做出决定，提供或撤销对身份的特定访问权限（参见5.18)。
5.17鉴别信息
控制 身份鉴别信息的分配和管理应由管理流程控制，包括就身份鉴别信息的适当处理向 员工提供建议。
目的 确保正确的实体鉴别并防止鉴别流程失败。
指南
鉴别信息的分配，分配和管理流程应确保： a)在注册过程中自动生成的个人口令或个人识别码(PIN)作为临时秘密鉴别信息是不可猜测的，并且对每个人都是唯一的，用户需要在第一次使用后进行更改； b)建立在提供新的、替换的或临时的鉴别信息之前验证用户身份的程序； c)鉴别信息，包括临时鉴别信息，以安全的方式（例如，通过经认证和受保护的信道)传输给用户，并且避免为此目的使用未受保护的（明文)电子邮件消息; d)用户确认收到鉴别信息； e)安装系统或软件后，立即更改供应商预定义或提供的默认身份验证信息； f)与鉴别信息的分配和管理相关的重要事件的记录，应妥善保存并赋予其机密属性，以及其保存方法获得批准（例如使用经批准的口令仓库工具)。
用户责任 应建议有权访问或使用身份鉴别信息的任何人确保： a)口令等秘密鉴别信息是保密的。个人秘密鉴别信息不会与任何人共享。在链接到多个用户或链接到非个人实体的身份的上下文中使用的秘密鉴别信息仅与授权人员共享； b)在收到受侵害通知或任何其他指示时，立即改变受影响的或侵害的鉴别信息； c)当口令用作身份验证信息时，将根据最佳实践建议选择强口令，例如： 1)口令不是基于其他人可以轻易猜测或使用个人相关信息（如姓名、电话号码和出生日期)获得的任何信息； 2)口令不是基于字典单词或其组合； 3)使用容易记忆的口令，并尽量包括字母数字和特殊字符； 4)口令有最小长度要求； d)不同的服务和系统不使用相同的口令； f)遵守这些规则的义务也包含在雇佣条款和条件中（参见6.2）。
口令管理系统 当口令用作身份验证信息时，口令管理系统应该： a)允许用户选择和更改自己的口令，并包括一个确认程序，以解决输入错误； b)根据"用户责任"中的良好实践建议[参见c]实施强口令； c)强制用户在首次登录时更改口令； d)必要时强制更改口令，例如在发生安全事故后，或者在雇佣关系终止或变更时，如果用户知道保持活动状态的身份（例如共享身份)的口令； e) 防止重复使用以前的口令； f)防止使用已被攻陷系统的常用口令和已受侵害的用户名、口令组合； g)输入口令时不在屏幕上显示口令； h)以受保护的形式存储和传输口令。 应根据批准的口令加密技术对口令进行加密和哈希处理（参见8.24)。
口令是一种常用的身份验证信息，也是验证用户身份的常用方法。其他类型的鉴别信息是密钥、存储在硬件令牌（例如智能卡)上的数据，这些硬件令牌产生鉴别代码和生物特征数据，例如虹膜扫描或指纹。更多信息可在1S0川EC24760系列中找到。 要求频繁更改口令可能不妥，因为用户可能会对频繁的更改感到厌烦，或忘记新口令，或将它们记在不安全的地方，或选择不安全的口令等。提供单，点登录(SSO)或其他身份鉴别管理工具（如口令仓库）可以减少用户需要保护的身份鉴别信息量，从而提高这种控制的有效性。但是，这些工具也会增加身份鉴别信息泄露的影响。 一些应用程序要求用户口令由独立机构分配。在这种情况下，"口令管理系统"的c)和d)不适用。
5.18访问权限
控制 应根据组织关于访问控制的专题策略和规则来提供、审查、修改和删除对信息和其 他相关资产的访问权限。
目的 确保根据业务要求定义和授权对信息和其他相关资产的访问。
指南
访问权限的提供和撤销 分配或撤销授予实体已验证身份的物理和逻辑访问权限的配置过程应包括： a)从信息和其他相关资产的所有者处获得使用信息和其他相关资产的授权（参见59)；由管理层单独批准访问权限也是合适的； b)顾及业务需求和组织关于访问控制的专题策略和规则； c)顾及职责分离，包括分离访问权限的批准和实施角色，以及分离冲突角色； d)确保在某人不需要访问信息和其他相关资产时移除访问权限，特别是确保及时移除已离开组织的用户的访问权限； e)考虑在有限的时间内给予临时准入权，并在期满时撤销，特别是对于临时人员或人员需要的临时准入； f) 验证授予的访问级别符合关于访问控制的专题策略（参见5.15)，并符合其他信息安全要求，如职责分离（参见5.3)； g)确保只有在成功完成授权程序后才激活访问权限（例如由服务提供商激活）； h)维护一个集中的记录，记录授予用户标识(ID、逻辑或物理)的对信息和其他相关资产的访问权限； i)修改已更改角色或工作的用户的访问权限； j)通过移除、撤销或替换密钥、鉴别信息、身份证或订阅来移除或调整物理和逻辑访问权限； k)维护用户的逻辑和物理访问权限的变更记录。
审核访问权限 对物理和逻辑访问权限的定期审核应顾及以下内容： a)在同一组织内发生任何变化（如工作变动、晋升、降职)或雇佣关系终止后，用户的访问权限（参见6.1至6.5)； b)特殊访问权的授权。
变更或终止雇佣关系前的考虑 在变更或终止雇佣关系之前，应根据对以下风险因素的评估，审查、调整或移除用户对信息和其他相关资产的访问权限： a)终止或变更是由用户发起还是由管理层发起，以及终止的原因； b)用户的当前职责； c)当前可访问的资产的价值。
其他： 应考虑根据业务需求建立用户访问角色，将一组访问权限汇总到典型的用户访问配置文件中。访问请求和访问权限的审查在这种角色级别比在特定权限级别更容易管理。 应考虑在人员合同和服务合同中加入条款，规定人员试图未经授权访问时的惩罚措施（参见5.20、6.2、6.4、6.6)。 在管理层发起解雇的情况下，心怀不满的人员或外部方用户可能会故意破坏信息或破坏信息处理设施。在有人锌职或被解雇的情况下，他们可能会收集信息供将来使用。 克隆是组织向用户分配访问权限的有效方式。但是，应该根据组织确定的不同角色谨慎进行，而不只是克隆一个具有所有相关访问权限的身份。克隆具有导致对信息和其他相关资产过度访问的固有风险。
5.19供应商关系中的信息安全
控制 应定义和实施流程和程序，以管理与使用供应商产品或服务相关的信息安全风险。
目的 在供应商关系中保持一致的信息安全水平。
指南
组织应当建立并向所有利益相关方传达关于供方关系的专题策略。 组织应当确定并实施过程和程序，以解决与使用供应商提供的产品和服务相关的安全风险。这也应该适用于组织对云服务提供商资源的使用。这些过程和程序应包括组织实施的过程和程序，以及组织要求供方实施的、开始使用供方的产品或服务、或者终止使用供方的产品和服务的过程和程序，如： a)确定并记录可能影响组织信息的机密性、完整性和可用性的供应商类型（如ICT服务、物流、公用事业、金融服务、ICT基础设施组件)； b)确定如何根据信息、产品和服务的敏感性评估和选择供应商（例如，通过市场分析、客户参考、文件审查、现场评估、认证)； c)评估和选择具有足够信息安全控制的供应商产品或服务，并对其进行审查；特别是供方实施的控制的准确性和完整性，以确保供方信息和信息处理的完整性，从而确保组织的信息安全； d)界定组织的信息、ICT服务和供应商可以访问、监测、控制或使用的有形基础设施； e)界定供应商提供的可能影响本组织信息的机密性、完整性和可用性的ICT基础设施组件和服务的类型； f)评估和管理与以下方面相关的信息安全风险： 1)供方对组织信息和其他相关资产的使用，包括来自潜在恶意供方人员的风险； 2)供应商提供的产品（包括这些产品中使用的软件组件和子组件)或服务的故障或漏洞； g)监控对每类供应商和访问类型的既定信息安全要求的遵守情况，包括第三方审查和产品验证； h)减少供应商的不合规行为，无论这是通过监控还是通过其他方式发现的； i) 处理与供应商产品和服务相关的事故和突发事件，包括组织和供应商的责任； j)韧性以及必要时的恢复和应急措施，以确保供方信息和信息处理的可用性，从而确保组织信息的可用性； k)根据供方的类型和供方对组织系统和信息的访问程度，对与供方人员互动的组织人员，进行有关适当的接触规则的专题策略、过程和程序以及行为的意识和培训； l)管理信息、其他相关资产和任何其他需要更改的内容的必要传递，并确保在整个传递期间维护信息安全； m)确保安全的终止供应商关系，包括如下需求： 1)取消访问权限； 2)信息处理； 3)确定项目期间开发的知识产权的所有权； 4)供应商或内包变更情况下的信息可移植性； 5)记录管理； 6)资产的返还； 7)安全处置信息和其他相关资产； 8)持续的保密要求； n)对供应商人员和设施的人身安全和物理安全的预期水平。
应考虑在供应商变得无法提供其产品或服务的情况下（如由于事故、供应商不再经 营、或由于技术进步不再提供某些组件)继续信息处理的程序，以避免在安排替代产品 或服务时的任何延迟（例如，提前确定替代供应商或始终使用替代供应商)。
当组织不可能对供应方提出要求时，组织应该： a)在决定选择供应商及其产品或服务时，考虑本控制中给出的指南； b)根据风险评估实施必要的补偿控制。 信息安全管理不足的供应商可能会将信息置于风险之中。应确定并应用控制措施来管理供应商对信息和其他相关资产的访问。例如，如果有对信息保密的特殊需要，可以使用保密协议或加密技术。另一个例子是当供应商协议涉及跨境信息传递或访问时的个人数据保护风险。组织需要意识到保护信息的法律或合同责任仍由组织承担。 供应商提供的ICT基础设施组件或服务控制不当也可能导致风险。故障或易受攻击的组件或服务可能会导致组织或其他实体的信息安全违背（例如，它们可能会导致恶意软件感染、攻击或对组织以外的实体造成其他伤害)。
5.20解决供应商协议中的信息安全问题
控制 应建立相关的信息安全要求，并根据供应商关系的类型与每个供应商达成一致。
目的 在供应商关系中保持一致的信息安全水平。
指南
应当建立供方协议并形成文件，以确保组织和供方对双方履行相关信息安全要求的义务有明确的理解。 为了满足确定的信息安全要求，可以考虑在协议中包含以下条款： a)对要提供或访问的信息以及提供或访问信息的方法的描述； b)根据组织的分类方案对信息进行分类（参见5.10、5.12、5.13)； c)组织自身的分类方案和供方的分类方案之间的映射； d)法律、法规、监管和合同要求，包括数据保护、个人可识别信息(PII)的处理、知识产权和版权，以及如何确保满足这些要求的说明； e)每个合同方实施一套商定的控制措施的义务，包括访问控制、绩效审查、监控、报告和审计，以及供应商遵守组织信息安全要求的义务； f)信息和其他相关资产的可接受使用规则，必要时包括不可接受的使用； g)供方人员使用组织信息和其他相关资产的授权和撤销授权的程序或条件（如通过授权使用组织信息和其他相关资产的供方人员的明确名单)； h)关于供应商ICT基础设施的信息安全要求；特别是，对每种信息和访问类型的最低信息安全要求，作为根据组织的业务需求和风险标准签订个别供应商协议的基础； i)承包商未能满足要求的赔偿和补救； j)事故管理要求和程序（尤其是事故补救期间的通知和协作)； k)特定程序和信息安全要求的培训和意识要求（如事故响应、授权程序)； l)分包的相关规定，包括需要实施的控制措施，如关于使用次级供应商的协议(如要求次级供应商承担与供应商相同的义务，要求拥有次级供应商清单并在任何变更前发出通知)； m)相关联系人，包括负责信息安全问题的联系人； n)在法律允许的情况下，对供应商人员的任何筛选要求，包括在筛选未完成或结果引起怀疑或担忧时进行筛选和通知程序的责任； o)与供应商流程相关的信息安全要求的第三方证明的证据和保证机制，以及关于控制有效性的独立报告； p)对与协议相关的供应商的流程和控制发起审核权利； q)供应商有义务定期提交控制有效性报告，并同意及时纠正报告中提出的相关问题； r)缺陷解决和冲突解决过程； s)提供符合组织需求的备份（在频率、类型和存储位置方面)； t)确保备用设施（即灾难恢复站点)的可用性，该备用设施不会受到与主设施相同的威胁，并考虑在主控制失效时的应变控制（备用控制)。 u)拥有变更管理流程，确保提前通知组织，并确保组织可以不接受变更； v)与信息分类相称的物理安全控制； w)信息传递控制，用于在物理传递或逻辑传递过程中保护信息； x)协议签订后的终止条款，包括记录管理、资产返还、信息和其他相关资产的安全处置以及任何持续的保密义务； y)提供可行方法，一旦属于组织的、由供方存储的信息不再被需要，就安全地销毁这些信息； z)确保在合同结束时，将支持移交给另一个供应商或组织本身。
组织应建立并维护与外各方的协议（如合同、谅解备忘录、信息共享协议）的登记册，以跟踪其信息的去向。组织还应定期审查、验证和更新其与外部方的协议，以确保这些协议仍然是必需的，并且符合相关信息安全条款的目的。
对于不同的组织和不同类型的供应商，协议可能有很大的不同。因此，应注意纳入解决信息安全风险的所有相关要求。 有关供应商协议的详细信息，参见ISO川EC27036系列。有关云服务协议，参见ISO/IEC19086系列。
5.21管理ICT供应链中的信息安全
控制 应定义和实施流程和程序，以管理与ICT产品和服务供应链相关的信息安全风险。
目的 在供应商关系中保持一致的信息安全水平。
指南
除了供应商关系的一般信息安全要求之外，还应考虑以下主题来解决ICT供应链安全中的信息安全问题： a)定义适用于ICT产品或服务采购的信息安全要求； b)要求ICT服务供应商在分包向本组织提供的部分ICT服务时，在整个供应链中宣传本组织的安全要求； c)要求ICT产品供应商在整个供应链中传播适当的安全做法，如果这些产品包括从其他供应商或其他实体（例如分包软件开发商和硬件组件供应商)购买或获得的组件； d)要求ICT产品供应商提供描述产品中使用的软件组件的信息； e)要求ICT产品供应商提供信息，说明其产品已实现的安全功能及其安全运行所需的配置； f)实施监测程序和可接受的方法，以验证交付的ICT产品和服务符合规定的安全要求。此类供应商审查方法的例子可包括渗透测试和对供应商信息安全操作的第三方证明的证明或验证； g)实施识别和记录产品或服务组件的流程，这些产品或服务组件对于维护功能至关重要，因此在组织外构建时需要更多的关注、审查和进一步跟进，特别是如果供应商将产品或服务组件的某些方面外包给其他供应商； h)获得可在整个供应链中追踪关键部件及其来源的保证； I)确保交付的ICT产品按预期运行，没有任何意外或不需要的特征； j)实施流程以确保来自供应商的组件是真实的，并且没有改变其规格。示例措施包括防篡改标签、加密哈希验证或数字签名。对不符合规格的性能的监控可能是篡改或伪造的指示。应在系统开发生命周期的多个阶段，包括设计、开发、集成、运行和维护，实施防篡改和防篡改措施； k)获得ICT产品达到所需安全水平的保证，例如通过正式认证或共同标准认可安排等评估计划； l)定义有关供应链的信息共享规则，以及组织和供应商之间任何潜在的问题和违背； m)实施管理ICT组件生命周期和可用性以及相关安全风险的具体流程。这包括管理由于供应商不再经营、或由于技术进步供应商不再提供这些组件而导致组件不再可用的风险。应当考虑替代供应商的确定程序以及将软件和能力转移给替代供应商的过程。
具体的ICT供应链风险管理做法建立在一般信息安全、质量、项目管理和系统工程做法的基础上，但并不取代它们。 建议各组织与供应商合作，了解ICT供应链以及对所提供的产品和服务有重要影响的任何事项。本组织可以通过在与供应商的协议中明确应由ICT供应链中其他供应商处理的事项，来影响ICT供应链信息安全做法。 ICT应该从有信誉的来源获得。软件和硬件的可靠性是质量控制的问题。虽然一个组织通常不可能检查其供应商的质量控制系统，但它可以根据供应商的信誉做出可靠的判断。 这里所说的ICT供应链包括云服务。ICT供应链的例子有： a)云服务供应，其中云服务提供商依赖于软件开发商、电信服务提供商、硬件提供商； b)物联网，其中服务涉及设备制造商、云服务提供商（例如物联网平台运营商)、移动和网络应用的开发者、软件库的供应商； c)托管服务，其中提供商依赖外部服务台，包括第一、第二和第三方支撑。 更多详情，包括风险评估指南，请参见ISO/IEC27036-3。 软件识别(SWID)标签还可以通过提供关于软件来源的信息来帮助实现供应链中更好的信息安全。更多详情见IS0/IEC19770-2。
5.22供应商服务的监控、审查和变更管理
控制 组织应当定期监视、评审、评估和管理供方信息安全实践和服务提供方面的变化。
目的 根据供应商协议，维护商定的信息安全和服务交付水平。
指南
供应商服务的监控、审查和变更管理应确保符合协议的信息安全条款和条件，信息安全事件和问题得到适当管理，并且供应商服务或业务状态的变化不会影响服务交付。 这应当包括管理组织与供应商之间关系的过程，以便： a)监控服务性能水平，以验证是否符合协议； b)监控供应商做出的变更，包括： 1)增强当前提供的服务； 2)任何新应用和系统的开发； 3)供应商策略和程序的修改或更新； 4)解决信息安全事故和提高信息安全的新的或变更的控制措施； c)监控供应商服务的变化，包括： 1)网络的改变和增强； 2)新技术的使用； 3)采用新产品或更新版本或发行版； 4)新的开发工具和环境； 5)服务设施物理位置的变化； 6)下级供应商的变更； 7)分包给另一个供应商； d)审查供应商提供的服务报告，并根据协议要求安排定期进度会议； e)对供应商和次级供应商进行审计，同时审查独立审计师的报告（如果有的话)，并跟进发现的问题； f)提供有关信息安全事件的信息，并根据协议以及任何支持性指南和程序的要求审查这些信息； g)审查供应商审计记录和信息安全事件、运营问题、故障的记录，跟踪与交付的服务相关的故障和中断； h)响应和管理任何确定的信息安全事件或事故； i)识别信息安全漏洞并进行管理； j)审查供应商与其自身供应商关系方面的信息安全； k) 确保供应商持续保持着满足需要的服务能力以及可行的计划，以确保在重大服务故障或灾难后能保持约定的服务连续性水平（参见5.29、5.30、5.35、5.36、8.14); l)确保供应商指派审查合规性和执行协议要求的责任； m)定期评估供应商是否保持着足够的信息安全水平。 管理供应商关系的责任应分配给指定的个人或团队。应提供足够的技术技能和资源，以监测协议的要求，特别是信息安全要求是否得到满足。当发现服务提供中的不足之处时，应采取适当的措施。 更多细节见1SO川EC27036-3。
5.23使用云服务的信息安全
控制 应根据组织的信息安全要求建立获取、使用、管理和退出云服务的流程。
目的 指定和管理云服务使用的信息安全。
指南
组织应该建立并向所有相关利益方传达关于云服务使用的专题策略。 组织应定义并传达其打算如何管理与云服务使用相关的信息安全风险。它可以是组织如何管理外部方提供的服务的现有方法的扩展或一部分（参见5.21和5.22)。 云服务的使用可能涉及云服务提供商和充当云服务客户的组织之间的信息安全和协作工作的共同责任。云服务提供商和作为云服务客户的组织的责任必须得到适当的定义和实施。
组织应当定义： a)与使用云服务相关的所有相关信息安全要求； b)云服务选择标准和云服务使用范围； c)与云服务的使用和管理相关的角色和职责； d)哪些信息安全控制由云服务提供商管理，哪些由作为云服务客户的组织管理； e)如何获取和利用云服务提供商提供的信息安全能力； f)如何获得云服务提供商实施的信息安全控制的保证； g)当一个组织使用多个云服务，特别是来自不同云服务提供商的云服务时，如何管理服务中的控制、接口和变化； h)处理与云服务使用相关的信息安全事件的程序； i)监控、审查和评估持续使用云服务来管理信息安全风险的方法； j)如何改变或停止使用云服务，包括云服务的退出策略。 云服务协议通常是预先定义的，不允许协商。对于所有云服务，组织应审查与云服务提供商签订的云服务协议。云服务协议应解决组织的机密性、完整性、可用性和信息处理要求，并具有适当的云服务级别目标和云服务质量目标。组织还应该进行相关的风险评估，以确定使用云服务的相关风险。任何与云服务的使用相关的残余风险都应该被组织的适当管理人员清楚地识别和接受。
云服务提供商与作为云服务客户的组织之间的协议应包括以下保护组织数据和服务可用性的条款： a)提供基于行业认可的架构和基础设施标准的解决方案； b)管理云服务的访问控制，以满足组织的要求； c)实施恶意软件监控和保护解决方案； d)在批准的地，点（如特定国家或地区）或特定管辖区内处理和存储组织的敏感信息； e)在云服务环境中发生信息安全事件时提供专门支持； f)确保在云服务进一步分包给外部供应商的情况下满足组织的信息安全要求（或禁止云服务被分包)； g)支持组织收集数字证据，同时顾及不同司法管辖区的数字证据法律法规； h)当组织想要退出云服务时，在适当的时间框架内提供适当的支持和服务可用性； i)根据作为云服务客户的组织所使用的云服务提供商的能力，提供所需的数据和配置信息备份，并酌情安全地管理备份； j)在服务提供期间或服务终止当时，提供并返回由作为云服务客户的组织拥有的配置文件、源代码和数据等信息。
作为云服务客户的组织，应考虑协议是否应要求云服务提供商在对向客户组织交付服务的方式做出任何实质性改变之前提供预先通知，包括： a)影响或改变云服务产品的技术基础设施变更（例如，重新定位、重新配置或硬件或软件变更)； b)在新的地理或法律管辖区处理或存储信息； c)使用其他对等的云服务提供商或其他分包商（包括改变现有供方或使用新供方)。 使用云服务的组织应该与其云服务提供商保持密切联系。这些联系使得能够相互交换关于使用云服务的信息安全的信息，包括云服务提供商和作为云服务客户的组织的机制，以监控每个服务特征并报告协议中包含的承诺的失败。
这项控制从云服务客户的角度考虑云安全。 有关云服务的其他信息可以在ISO/IEC17788、ISO/IEC17789和I1SO/IEC22123-1找到。与支持退出策略的云可移植性相关的细节可以在ISO/IEC19941中找到。ISO/IEC27017中描述了与信息安全和公共云服务相关的细节。在ISO/IEC27018中描述了与充当P处理器的公共云中的P‖保护相关的细节。云服务的供应商关系由ISO/IEC27036-4和云服务协议涵盖，其内容由ISO/IEC19086系列处理，安全和隐私由ISO/IEC19086-4专门涵盖。
5.24规划和准备管理信息安全事故
控制 组织应通过定义、建立和传达信息安全事故管理流程、角色和职责来计划和准备好 管理信息安全事故。
目的 确保对信息安全事故做出快速、有效、一致和有序的响应，包括就信息安全事件进 行沟通。
指南
角色和责任 组织应建立适当的信息安全事故管理流程。应确定执行事故管理程序的角色和职责，并有效地传达给相关的内部和外部利益相关方。 应考虑以下几点： a)建立报告信息安全事件的通用方法，包括联系人（参见6.8)； b)建立事故管理流程，为组织提供管理信息安全事故的能力，包括管理、记录、检测、分类、优先排序、分析、沟通和协调相关方； c)建立事故响应流程，为组织提供评估、响应信息安全事故并从中吸取教训的能カ； d)仅允许有能力的人员处理组织内与信息安全事故相关的问题。应向这些人员提供程序文件和定期培训； e)建立确定事故响应人员所需培训、认证和职业发展的需求的流程。
事故管理程序 信息安全事故管理的目标应与管理层达成一致，并应确保负责信息安全事故管理的人员了解组织处理信息安全事故的优先顺序，包括基于潜在后果和严重性的处置时间框架。应实施事故管理程序来实现这些目标和优先级。 管理层应确保创建信息安全事件管理计划，考虑为以下活动开发和实施的不同场景和程序： a)根据构成信息安全事故的标准评估信息安全事件； b)监控（参见8.15和8.16)、检测（参见8.16)、分类（参见5.25)、分析和报告（参见6.8)信息安全事件和事故（通过人工或自动方式)； c)依据事件的类型和类别、危机管理的可能激活和连续性计划的激活、 事件的受控恢复以及与内部和外部相关方的沟通，管理信息安全事故直至结束，包括响应和上报（参见5.26）； d)与内部和外部相关方的协调，如职能机构、外部利益团体和论坛、供应商和客户（参见5.5和5.6）； e)记录事故管理活动； f)证据的处理（参见5.28)； g) 根本原因分析或事后程序； h) 确认吸取的经验教训以及事故管理程序或一般信息安全控制措施所需的任何改进。
报告程序 报告程序应包括： a)发生信息安全事件时要采取的行动（例如，立即注意所有相关细节，如故障发生和屏幕上的消息，立即向联系人报告，并仅采取协调行动)； b)使用事故报表为员工报告信息安全事故时所有必要活动提供支持； c)适当的反馈流程，以确保在问题得到解决和结束后，尽可能向报告信息安全事件的人员通知结果； d)创建事故报告。 在实施事故管理程序时，应考虑在规定的时间范围内向相关利益方报告事故的任何外部要求（例如向监管机构报告违规的要求）。
其他信息 信息安全事故可能超越组织和国家的界限。为了响应此类事故，适当地协调响应并与外部组织共享关于这些事故的信息是有益的。 1SO/IEC27035中提供了有关信息安全事故管理的一系列详细指南。
5.25信息安全事件的评估和决策
5.26应对信息安全事故
5.27从信息安全事故中吸取教训
5.28收集证据
5.29中断期间的信息安全
5.30ICT为业务连续性做好准备
5.31法律、法规、监管和合同要求
5.32知识产权
5.33记录保护
5.34PII隐私和保护
5.35信息安全独立审查
5.36信息安全策略、规则和标准的遵从性
5.37文件化的操作程序
6人员控制
6.1筛选
6.2雇佣条款和条件
6.3信息安全意识、教育和培训
6.4纪律程序
6.5雇佣关系终止或变更后的责任
6.6保密或不披露协议
6.7远程工作
6.8报告信息安全事件
7物理控制
7.1物理安全周界
7.2物理入口
7.3保护办公室、房间和设施
7.4物理安全监控
7.5抵御物理和环境威胁
7.6在安全区域工作
7.7桌面清理和屏幕清理
7.8设备安置和保护
7.9场外资产的安全
7.10存储介质
7.11支持性设施
7.12布线安全
7.13设备维护
7.14设备的安全作废或再利用
8技术控制
8.1用户终端设备
8.2特殊访问权
8.3信息访问约束
8.4获取源代码
8.5安全身份认证
8.6容量管理
控制 应根据当前和预期的容量要求监控和调整资源的使用。
目的 确保信息处理设施、人力资源、办公室和其他设施所需的能力。
指南
应确定信息处理设施、人力资源、办公室和其他设施的能力要求，同时考虑相关系统和流程的业务重要性。 应进行系统调整和监控，以确保并在必要时提高系统的可用性和效率。 组织应对系统和服务进行压力测试，以确认有足够的系统容量来满足峰值性能要求。 检测性控制应该到位，以便在需要的时候指出问题。 对未来的能力需求的预测应考虑新的业务和系统需求，以及组织信息处理能力的当前和预测趋势。 应特别注意采购周期长或成本高的任何资源。因此，管理者、服务或产品所有者应该监控关键系统资源的利用率。 管理者应使用容量信息来识别和避免潜在的资源限制和对关键人员的依赖，因为这些可能会对系统安全或服务造成威胁，并计划适当的措施。
可以通过增加容量或减少需求来提供足够的容量。应考虑以下因素来增加容量： a)雇佣新员工； b)获得新的设施或空间； c)获得更强大的处理系统、内存和存储； d)利用云计算，云计算具有直接解决容量问题的固有特性。云计算具有弹性和可扩展性，能够按需快速扩展或削减特定应用程序和服务的可用资源。 2.为减少对组织资源的需求，应考虑以下因素： e)删除过时数据（磁盘空间）； f)作废已达到保存期的硬拷贝记录（释放搁置空间）； g)应用程序、系统、数据库或环境的退役； h)优化批处理过程和时间表； i)优化应用程序代码或数据库查询； j)如果消耗资源的服务不是关键的（例如视频流），拒绝或限制其带宽。 对于任务关键型系统，应考虑记录容量管理计划。
8.7防范恶意软件
8.8技术漏洞的管理
8.9配置管理
控制 应建立、记录、实施、监控和审查硬件、软件、服务和网络的配置，包括安全配 置。
目的 确保硬件、软件、服务和网络在所需的安全设置下正常运行，并且配置不会因未经 授权或不正确的更改而改变。
指南
常规 组织应定义并实施流程和工具，以在硬件、软件、服务（例如云服务）和网络、新安装的系统以及运营系统的生命周期内强制实施已定义的配置（包括安全配置）。 角色、职责和程序应到位，以确保对所有配置更改的恰当控制。
标准模板 应定义硬件、软件、服务和网络安全配置的标准模板： a)使用公开可用的指南（例如，来自供应商和独立安全组织的预定义模板）； b)考虑所需的保护级别，以确定足够的安全级别； c)支持组织的信息安全策略、专题策略、标准和其他安全要求； d)考虑组织环境中安全配置的可行性和适用性。 当需要应对新的威胁或漏洞时，或者当引入新的软件或硬件版本时，应定期审查和更新这些模板。 为硬件、软件、服务和网络的安全配置建立标准模板时，应顾及以下事项： a)最小化具有特权或管理员级别访问权限的身份的数量； b)禁用不必要、未使用或不安全的身份； c)禁用或限制不必要的功能和服务； d)约束对高权能的实用程序和主机参数设置的访问； e)同步时钟； f)安装后立即更改供应商默认验证信息，如默认密码，并检查其他与安全相关的重要参数的默认值； g)调用超时工具，该工具在预定的不活动时段之后自动注销计算设备； h)验证是否符合许可证要求（参见5.32）。
管理配置 应当记录硬件、软件、服务和网络的既定配置，并且应当维护所有配置更改的日志。记录应安全存放。这可以通过多种方式实现，例如配置数据库或配置模板。 配置变更应遵循变更管理流程（参见8.32）。相关的配置记录可包含： a)资产的最新所有者或联系人信息； b)上次更改配置的日期； c)配置模板的版本； d)与其他资产配置的关系。
监控配置 应使用一套全面的系统管理工具（例如维护实用程序、远程支持、企业管理工具、备份和恢复软件)来监控配置，并应定期审查配置，以验证配置设置、评估密码强度并评估所执行的活动。实际配置可以与定义的目标模板进行比较。任何偏差都应纠正，可以自动执行已定义的目标配置，或人工分析偏差并采取纠正措施。
8.10信息删除
8.11数据遮盖
8.12防止数据泄漏
8.13信息备份
8.14信息处理设备的冗余
8.15日志
8.16活动监测
8.17时钟同步
8.18特权实用程序的使用
8.19在操作系统上安装软件
8.20网络安全
8.21网络服务的安全性
8.22网络隔离
8.23web过滤
8.24密码学的使用
8.25安全开发生命周期
8.26应用程序安全要求
8.27安全系统架构和工程原理
8.28安全编码
8.29开发和验收中的安全性测试
8.30外包开发
8.31开发、测试和生产环境的分离
8.32变更管理
8.33测试信息
8.34审计测试期间信息系统的保护