ISO/IEC 27002:2022 信息安全，网络安全与隐私保护 ——信息安全控制
试译交流版
说明
2022年2月，国际标准化组织发布更新发布了信息安全、网络安全和隐私保护——信息安全控制（ISO/IEC 27002:2022），以作为组织根据信息安全管理体系认证标准定制和实施信息安全控制措施的指南。
新标准的更新变化为新环境下网络安全、数据安全治理和管理提供了先进的思路和参考框架，为尽快将新标变化纳入数据安全治理咨询服务知识库，安全咨询事业部组织专家力量进行翻译整理，现予发布，允许在保持文件原貌的前提下交流共享。
本试译交流版主要翻译人员为安全咨询事业部高级安全顾问汤季洪(CISSP /CISP /CCSP /CCSI /CEH /RHCA /RHCE /MCSE /MCDBA /VCP)，并得到了盘茜(CISSP /CISP)女士的大力支持。
由于译者水平有限，错误或不当之处在所难免，请参照英文原版以准，并请拨冗批评指正。可联系汤季洪 [13372520776(微信同号)或tangjihong@secsmart.com] 。
闪捷信息科技有限公司?安全咨询事业部
2022年3月18日
序
ISO（国际标准化组织）和IEC（国际电工委员会）构成了全球标准化的专门体系。作为ISO或IEC成员的国家机构通过各自组织建立的技术委员会参与国际标准的制定，以处理特定领域的技术活动。ISO和IEC技术委员会在共同感兴趣的领域进行合作。与ISO和IEC保持联系的其他政府和非政府国际组织也参与此项工作。
ISO/IEC指令第1部分描述了用于编制本文件的程序以及旨在进一步维护本文件的程序。特别是，应注意不同类型的文件需要不同的审批标准。本文件根据ISO/IEC指令第2部分的编辑规则起草（参见www.iso.org/directives或者www.iec.ch/members_experts/refdocs ）。
请注意，本文件中的某些内容可能是专利权的主题。ISO和IEC不负责识别任何或所有此类专利权。在文档开发过程中确定的任何专利权的详细信息将在引言和/或收到的ISO专利声明列表中列出（参见www.iso.org/patents）或收到的IEC专利声明列表（参见patents.iec.ch）。
本文件中使用的任何商品名称都是为了方便用户而提供的信息，并不构成认可。
有关标准的自愿性质的解释、与合格评定相关的ISO特定术语和表述的含义，以及有关ISO遵守《技术性贸易壁垒（TBT）中遵守世界贸易组织（WTO）原则》的信息，请参见www.iso.org/iso/foreword.html。IEC的有关信息请参见www.iec.ch/understanding-standards。
本文件由ISO/IEC JTC 1联合技术委员会信息技术分委员会SC 27信息安全、网络安全和隐私保护编写。
第三版取消并取代了第二版（ISO/IEC 27002：2013），包含第二版的技术修订ISO/IEC 27002:2013/Cor.1:2014和ISO/IEC 27002:2013/Cor.2:2015。
主要变化如下：
??— 修改了标题；
??— 改变了文档的结构，使用简单的分类法和相关属性来呈现控制；
??— 一些控制被合并，一些被删除，一些新的控制被引入。
完整的对照见附件B。
关于本文件的任何反馈或问题应提交给使用者所在国家或地区的标准机构。这些机构的完整清单可在以下网址找到：
www.iso.org/members.html
www.iec.ch/national-committees
0 介绍
0.1 背景和语境
本文件适用于各种类型和规模的组织。它将用作在基于ISO/IEC 27001的信息安全管理体系（ISMS）中确定和实施信息安全风险处理控制的参考。它还可以用作组织确定和实施普遍接受的信息安全控制措施的指导文档。此外，考虑到特定的信息安全风险环境，本文件旨在用于制定行业和组织特定的信息安全管理准则。本文件中未包括的组织或环境特定的控制措施可根据需要通过风险评估来确定。
各种类型和规模的组织（包括公共和私营部门、商业和非营利组织）以多种形式创建、收集、处理、存储、传输和处置信息，包括电子、物理和口头形式（例如对话和演示）。
信息的价值超越了文字、数字和图像：知识、概念、想法和品牌都是信息的无形形式。在一个相互关联的世界中，信息和其他相关资产值得或需要针对各种风险源进行保护，无论这些风险源是自然的、意外的还是蓄意的。
信息安全是通过实施一套适当的控制措施来实现的，包括策略、规则、流程、程序、组织结构以及软件和硬件功能。为了满足其特定的安全和业务目标，组织应在必要时定义、实施、监控、审查和改进这些控制措施。诸如ISO/IEC 27001中规定的ISMS对组织的信息安全风险采取整体的、协调的观点，以便在一致的管理系统的总体框架内确定和实施一套全面的信息安全控制。
许多信息系统，包括它们的管理和操作，都没有按照ISO/IEC 27001和本文件中规定的ISMS来设计安全性。仅通过技术措施实现的安全级别是有限的，应该得到适当的管理活动和组织流程的支持。在进行风险处理时，确定哪些控制措施应该到位需要仔细规划并注意细节。
成功的ISMS需要组织中所有人员的支持。它还可能需要其他相关方的参与，如股东或供应商。也可能需要相关领域专家的建议。
一个适当、充分和有效的信息安全管理体系为组织的管理层和其他相关方提供保证，确保他们的信息和其他相关资产得到合理的保护，免受威胁和伤害，从而使组织能够实现既定的业务目标。
0.2 信息安全要求
组织必须确定其信息安全要求。信息安全要求有三个主要来源：
??a）考虑到组织的总体业务战略和目标，对组织面临的风险进行评估。这可以通过特定于信息安全的风险评估来促进或支持。这应导致确定必要的控制措施，以确保本组织的剩余风险符合其风险接受标准；
??b） 组织及其相关方（贸易伙伴、服务提供商等）必须遵守的法律、法规、规章和合同要求，以及他们的社会文化环境；
??c）组织为支持其运营而开发的信息生命周期所有步骤的一系列原则、目标和业务要求。
0.3 控制
控制被定义为改变或保持风险的措施。本文件中的一些控制措施是改变风险的控制措施，而其他控制措施则保持风险。例如，信息安全策略只能保持风险，而遵守信息安全策略可以改变风险。此外，一些控制表现为在不同的风险语境下相同的通用措施。本文件提供了从国际公认的最佳实践中总结出来的组织、人员、物理和技术信息安全控制的通用组合。
0.4 确定控制
确定控制取决于组织在风险评估后做出的决策，并具有明确定义的范围。与已识别风险相关的决策应基于组织采用的风险接受标准、风险处理方案和风险管理方法。控制措施的确定还应考虑到所有相关的国家和国际法律和法规。控制措施的确定还取决于控制措施相互作用以提供深度防御的方式。
组织可以根据需要设计控制或从任何来源识别控制。在指定此类控制措施时，组织应根据实现的业务价值考虑实施和运行控制措施所需的资源和投资。请参见ISO/IEC 27016，了解有关ISMS投资决策的指导，以及这些决策在竞争资源需求背景下的经济后果。
为实施控制措施而部署的资源应该与在没有这些控制的情况下安全事故可能产生的业务影响之间寻求平衡。风险评估的结果应有助于指导和确定适当的管理措施、管理信息安全风险的优先级以及实施防范这些风险所需的控制措施。
本文件中的一些控制措施可视为信息安全管理的指导原则，适用于大多数组织。有关确定控制和其他风险处理选项的更多信息，请参见ISO/IEC 27005。
0.5 制定组织的个性化指南
该文件可被视为制定组织的个性化指南的起点。并不是本文件中的所有控制和指导都适用于所有组织。还可能需要本文件中未包含的其他控制措施和指南来满足组织的特定需求和已识别的风险。当制定的文件包含额外的指南或控制措施时，包含本文件中条款的交叉引用以供将来参考会很有帮助。
0.6 生命周期考虑因素
信息有一个生命周期，从创建到处置。在整个生命周期中，信息的价值和风险可能会有所不同（例如，未经授权披露或窃取公司的财务账目在发布后并不严重，但完整性仍然至关重要）。因此，在所有阶段，信息安全在某种程度上都很重要。
信息系统和与信息安全相关的其他资产都有生命周期，在这些生命周期内，它们被构思、规定、设计、开发、测试、实施、使用、维护，并最终退役和处置。每个阶段都应该考虑信息安全。新的系统开发项目和对现有系统的改变提供了改善安全控制的机会，同时考虑到本组织的风险和从事故中吸取的教训。
0.7 相关国际标准
本文件提供了许多不同组织中普遍应用的各种信息安全控制的指南，而ISO/IEC 27000系列中的其他文档提供了有关信息安全管理整体流程的其他方面的补充建议或要求。
有关ISMS和文件系列的一般介绍，请参考ISO/IEC 27000。ISO/IEC 27000提供了一个词汇表，定义了ISO/IEC 27000文件系列中使用的大多数术语，并描述了该系列每个成员的范围和目标。
还有一些针对特定行业的标准，这些标准包含针对特定领域的额外控制措施（例如，针对云服务的ISO/IEC 27017标准、针对隐私的ISO/IEC 27701标准、针对能源的ISO/IEC 27019标准、针对电信组织的ISO/IEC 27011标准以及针对健康的ISO 27799标准）。此类标准包含在参考书目中，其中一些参考了第5-8条中的指南和其他信息部分。
1 范围
本文件提供了一套通用的信息安全控制参考，包括实施指南。旨在供组织用来：
??a）在基于ISO/IEC 27001的信息安全管理体系（ISMS）的范围内；
??b）根据国际公认的最佳实践实施信息安全控制；
??c）制定特定于组织的信息安全管理准则。
2 规范性引用文件
本文件中没有规范性引用文件。
3 术语，定义和缩写词
3.1 术语和定义
就本文件而言，以下术语和定义适用。
ISO和IEC在以下地址维护用于标准化的术语数据库：
??— ISO在线浏览平台：https://www.iso.org/obp
??— IEC电子词典：https://www.electropedia.org/
3.1.1 访问控制 access control
确保基于业务和信息安全要求授权和限制对资产（3.1.2）的物理和逻辑访问的方法。
3.1.2 资产 asset
任何对组织有价值的事物。
条目注释1：在信息安全环境中，可以区分两种资产：
??— 主要资产：
??????— 信息；
??????— 业务流程（3.1.27）和活动；
??— 所有类型的支持资产（主要资产所依赖的），例如：
??????— 硬件；
??????— 软件；
??????— 网络；
??????— 工作人员（3.1.20）；
??????— 站点；
??????— 组织结构。
3.1.3 攻击 attack
未授权的破坏、更改、禁用、访问资产（3.1.2）的成功或不成功的尝试，或任何试图暴露、窃取或未经授权使用资产（3.1.2）的行为。
3.1.4 鉴别 authentication
保证实体（3.1.11）声称的特征属性是正确的。
3.1.5 真实性 authenticity
一个实体（3.1.11）是它所声称的那样的属性。
3.1.6 监管链 chain of custody
从一个时间点到另一个时间点，材料的可证明的持有、移动、处理和定位
条目注释1：在ISO/IEC 27002环境下，材料包括信息和其他相关资产（3.1.2）。
[资料来源：ISO/IEC 27050-1：2019，3.1，另含修订——添加“条目注释1”]
3.1.7 机密消息 confidential information
不打算对未经授权的个人、实体（3.1.11）或过程（3.1.27）可用或向其披露的信息。
3.1.8 控制 control
保持和/或改变风险的措施
条目注释1：控制包括但不限于任何过程（3.1.27）、策略（3.1.24）、设备、实践或其他保持和/或改变风险的条件和/或行动。
条目注释2：控制可能并不总是产生预期或假定的改变效果。
[资料来源：ISO 31000：2018，3.8]
3.1.9 中断 disruption
一种事故，无论是预期的还是未预期的，都会导致产品和服务的预期交付相对于组织的目标发生计划外的负面偏离。
[资料来源：ISO 22301：2019，3.10]
3.1.10 终端设备 endpoint device
联网的信通技术（ICT）硬件设备。
条目注释1：端点设备可以指台式计算机、笔记本电脑、智能手机、平板电脑、瘦客户机、打印机或其他专用硬件，包括智能电表和物联网（IoT）设备。
3.1.11 实体 entity
与具有可识别的独特存在的领域的运营目的相关的项目。
条目注释1：一个实体应有一个物理或逻辑的具象化实例。
例如个人、组织、设备、一组像这样罗列的事物、电信服务的个人订户、SIM卡、护照、网络接口卡、软件应用、服务或网站等。
[资料来源：国际标准化组织/IEC 24760-1：2019，3.1.1]
3.1.12 信息处理设施 information processing facility
任何信息处理系统、服务或基础设施，或容纳信息的物理位置。
[资料来源：ISO/IEC 27000：2018，3.27，修改——“设施facilities”替换为“设施facility”。]
3.1.13 信息安全的违背 information security breach
危及信息安全，导致传输、存储或以其他方式处理的受保护信息遭到意外破坏、丢失、篡改、泄露或访问。
3.1.14 信息安全事件 information security event
表明可能发生信息安全的破坏（3.1.13）或控制失败（3.1.8）的事件
[资料来源：ISO/IEC 27035-1：2016，3.3，修改——“信息安全的违背breach of information security”替换为“信息安全的违背information security breach”]
3.1.15 信息安全事故 information security incident
一个或多个相关且已确定的信息安全事件（3.1.14）,可能会损害组织的资产（3.1.2）或干扰其运营
[资料来源：ISO/IEC 27035-1：2016，3.4]
3.1.16 信息安全事故管理 information security incident management
采用一贯的、有效的方法处理信息安全事故（3.1.15）
[资料来源：ISO/IEC 27035-1：2016，3.5]
3.1.17 信息系统 information system
一组应用程序、服务、信息技术资产（3.1.2）或其他信息处理部件。
[资料来源：国际标准化组织/IEC 27000：2018，3.35]
3.1.18 利益相关方 interested party/stakeholder
能够影响决策或活动、被决策或活动影响或认为自己受决策或活动影响的个人或组织。
[资料来源：国际标准化组织/IEC 27000：2018，3.37]
3.1.19 不可否认性 non-repudiation
证明声称的事件或行动及其发起实体发生的能力（3.1.11）
3.1.20 工作人员 personnel
在组织的指导下工作的人员
条目注释1：工作人员的概念包括组织的成员，如理事机构、最高管理层、雇员、临时工作人员、承包商和志愿者。
3.1.21 个人可识别信息 personally identifiable information/PII
（a）可用于在信息和与信息相关的自然人之间建立联系的任何信息，或（b）直接或间接与自然人相关联的任何信息。
条目注释1：定义中的“自然人”是指PII主体（3.1.22）。要确定PII主体是否可识别，应考虑持有数据的隐私利益相关方或任何其他方可以合理使用的所有方法，以建立PII集和自然人之间的联系。
[资料来源：ISO/IEC 29100：2011/Amd.1：2018，2.9]
3.1.22 PII主体 PII principal
与PII个人可识别信息（3.1.21）相关的自然人。
条目注释1：根据司法管辖区和特定的数据保护和隐私立法，也可以使用同义词“数据主体”代替术语“PII主体”。
[资料来源：国际标准化组织/IEC 29100：2011，2.11]
3.1.23 PII处理者 PII processor
代表PII控制者并根据其指示处理PII个人可识别信息（3.1.21）的隐私利益相关方。
[资料来源：国际标准化组织/IEC 29100：2011，2.12]
3.1.24 策略 policy
由最高管理者正式表达的组织的意图和方向
[资料来源：ISO/IEC 27000：2018，3.53]
3.1.25 隐私影响评估 privacy impact assessment
识别、分析、评估、咨询、沟通和规划处理PII个人可识别信息（3.1.21）的潜在隐私影响的整体流程（3.1.27），在组织更广泛的风险管理框架内制定
[资料来源：ISO/IEC 29134：2017，3.7，修改——删除条目注释1。]
3.1.26 程序 procedure
开展活动或过程（3.1.27）的特定方式。
[资料来源：ISO 30000：2009，3.12]
3.1.27 过程 process
使用或转换输入以交付结果的一组相互关联或相互作用的活动
[资料来源：ISO 9000：2015，3.4.1，修改——删除条目注释]。
3.1.28 记录 record
组织或个人在履行法律义务或业务交易中，被作为证据、同时也作为资产创建、接收和维护的信息（3.1.2）
条目注释1：此处的法律义务包括所有法律、法规、监管和合同要求。
[资料来源：ISO 15489-1：2016，3.14，修改——添加“条目注释1”。]
3.1.29 恢复点目标 recovery point objective/RPO
发生中断（3.1.9）后数据将要恢复到的时间点。
[资料来源：ISO/IEC 27031：2011，3.12，修改——“必须must”替换为“将要are to be”。]
3.1.30 恢复时间目标 recovery time objective/RTO
发生中断（3.1.9）后，服务和/或产品以及支持系统、应用程序或功能恢复到最低水平所历经的时长。
[资料来源：ISO/IEC 27031：2011，3.13，修改——“必须must”替换为“将要are to be”。]
3.1.31 可靠性 reliability
与预期行为和结果一致的特性。
3.1.32 规则 rule
被接受的原则或指示，说明组织要求做什么、允许什么或不允许什么。
条目注释1：规则可以在专题策略（3.1.35）和其他类型的文件中正式表述。
3.1.33 敏感信息 sensitive information
由于对个人、组织、国家安全或公共安全的潜在不利影响，需要防止其不可用、未经授权的访问、修改或公开披露的信息。
3.1.34 威胁 threat
可能对系统或组织造成损害的意外事故的潜在原因
[来源：ISO/IEC 27000：2018，3.74]
3.1.35 专题策略
由适当层级的管理者正式表达的，关于特定对象或主题的意图和方向。
条目注释1：专题策略可以正式表达规则（3.1.32）或组织标准。
条目注释2：一些组织对这些专题策略使用其他术语。
条目注释3：本文档中提及的专题策略与信息安全相关。关于访问控制的专题策略示例（3.1.1），关于桌面清晰和屏幕清晰的专题策略。
3.1.36 用户 user
有权访问组织信息系统（3.1.17）的相关方（3.1.18）。
比如工作人员（3.1.20）、客户、供应商。
3.1.37 用户终端设备 user endpoint device
用户用来访问信息处理服务的终端设备（3.1.10）。
条目注释1：用户终端设备可以指台式计算机、膝上型计算机、智能电话、平板电脑、瘦客户机等。
3.1.38 脆弱性 vulnerability
可能被一个或多个威胁（3.1.34）利用的资产（3.1.2）或控制（3.1.8）的弱点
[资料来源：国际标准化组织/IEC 27000：2018，3.77]
3.2 缩写词
ABAC
attribute-based access control
基于属性的访问控制
ACL
access control list
访问控制列表
BIA
business impact analysis
业务影响分析
BYOD
bring your own device
自带设备办公
CAPTCHA
completely automated public Turing test to tell computers and humans apart
全自动公共图灵测试，区分计算机和人类
CPU
central processing unit
中央处理单元
DAC
discretionary access control
自主访问控制
DNS
domain name system
域名系统
GPS
global positioning system
全球定位系统
IAM
identity and access management
身份与访问管理
ICT
information and communication technology
信息与通讯技术
ID
Identifier
标识符
IDE
integrated development environment
集成开发环境
IDS
intrusion detection system
入侵检测系统
IoT
internet of things
物联网
IP
internet protocol
互联网协议
IPS
intrusion prevention system
入侵防御系统
IT
information technology
信息技术
ISMS
information security management system
信息安全管理体系
MAC
mandatory access control
强制访问控制
NTP
network time protocol
网络时间协议
PIA
privacy impact assessment
隐私影响分析
PII
personally identifiable information
个人可识别信息
PIN
personal identification number
个人识别码
PKI
public key infrastructure
公钥基础设施
PTP
precision time protocol
精密时钟协议
RBAC
role-based access control
基于角色的访问控制
RPO
recovery point objective
恢复点目标
RTO
recovery time objective
恢复时间目标
SAST
static application security testing
静态应用程序安全测试
SD
secure digital
安全数字
SDN
software-defined networking
软件定义网络
SD-WAN
software-defined wide area networking
软件定义广域网
SIEM
security information and event management
安全信息与事件管理
SMS
short message service
短消息服务
SQL
structured query language
结构化查询语言
SSO
single sign on
单点登录
SWID
software identification
软件识别
UEBA
user and entity behaviour analytics
用户和实体行为分析
UPS
uninterruptible power supply
不间断电源
URL
uniform resource locator
统一资源定位符
USB
universal serial bus
通用串行总线
VM
virtual machine
虚拟机
VPN
virtual private network
虚拟专用网
WiFi
wireless fidelity
无线相容性认证
4 本文件的结构
4.1 章节
本文件基于如下结构：
??a）组织控制（第5章）
??b）人员控制（第6章）
??c）物理控制（第7章）
??d）技术控制（第8章）
并包含两个附录：
??附录A ——使用属性
??附录B ——与ISO/IEC 27002：2013的对应关系
附录A 解释了组织如何使用属性（参见4.2），根据本文件中定义的控制属性或自己创建的控制属性创建自己的视图。
附录B 显示了本版ISO/IEC 27002与之前的2013版之间的对应关系?。
4.2 主题和属性
第5章至第8章中给出的控制分类被称为主题。控制分为以下几类：
??a） 人，如果涉及个人；
??b）物理的，如果涉及物理对象；
??c）技术，如果涉及技术；
??d）否则，被归类为组织。
组织可以使用属性来创建不同的视图，这些视图是从主题的不同角度对控制的不同分类。属性可用于在不同的视图中为不同的受众筛选、排序或呈现控制。附录A解释了如何实现这一点，并提供了一个视图示例。
举例来说，本文件中的每个控制都与具有相应属性值的五个属性相关联（以“#”开头以使其可搜索），如下所示：
??a）控制类型
????控制类型是一种属性，用于从是何时以及如何改变风险的角度来认识控制，这些风险与信息安全事件的发生相关。
????属性值包括
????预防性：旨在防止信息安全事件发生的控制措施；
????检测性：信息安全事件发生时起作用的控制措施；
????纠正性：信息安全事件发生后起作用的控制措施。
??b）信息安全特性
????信息安全特性是用于从有助于保护信息的哪一项品质的角度来认识控制的一种属性。
????属性值由机密性、完整性和可用性组成。
??c）网络安全概念
????网络安全概念是用于从与ISO/IEC 27110所描述的网络安全框架中定义的网络安全概念的关联的角度来认识控制的属性。
????属性值包括识别、保护、检测、响应和恢复。
??d）运营能力
????运营能力是从业者从信息安全能力的角度来认识控制的属性。属性值共15个，包括治理、资产管理、信息保护、人力资源安全、物理安全、系统和网络安全、应用安全、安全配置、身份和访问管理、威胁和漏洞管理、连续性、供应商关系安全、法律与合规性、信息安全事件管理和信息安全保证。
??e）安全域
????安全域属性从四个信息安全域角度来认识控制，属性值包括治理与生态系统、保护、防御和韧性。
????治理与生态系统 包括“信息系统安全治理&风险管理”和“生态系统网络安全管理”（包括内部和外部利益相关者）；
????保护 包括“IT安全架构”、“IT安全管理”、“身份和访问管理”、“IT安全维护”和“物理和环境安全”；
???? 防御 包括“检测”和“计算机安全事件管理”；
???? 韧性 包括“业务连续性”和“危机管理”。
选择本文件中给出的属性是因为它们被认为是通用的，足以供不同类型的组织使用。组织可以选择忽略本文件中给出的一个或多个属性。他们还可以创建自己的属性（带有相应的属性值）来创建自己的组织视图。附件A.2包括了这些属性的例子。
4.3 控制的布局
以下章节对每个控制的描述使用如下布局结构：
??抬头： 控制的简称；
??属性表： 显示给定控制的每个属性的值的表；
??控制： 控制是什么；
??目的： 为什么要实施控制；
??指南： 应该如何实施控制；
??其他信息： 说明性文本或对其他相关文档的引用。
另外，由于某些控制的指南很长且涉及多个主题，文本中会使用副标题以提高可读性。此类标题不一定在所有指南文本中使用。副标题加了下划线。
5 组织控制
5.1 信息安全策略
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #治理 | #治理与生态系统 #韧性 |
控制
应定义信息安全策略和专题策略，由管理层批准，发布，传达给相关人员和利益相关方并得到他们的认可，并在计划的时间间隔和发生重大变化时进行审查。
目的
根据业务、法律、法规、监管和合同要求，确保管理方向和信息安全支持的持续适用性、充分性和有效性。
指南
在最高级别，组织应定义由最高管理层批准的“信息安全策略”，该策略规定了组织管理其信息安全的方法。
信息安全策略应顾及来自以下方面的要求：
??a）业务战略和要求；
??b）法规、立法和合同；
??c）当前和预计的信息安全风险和威胁。
信息安全策略应包含关于以下方面的声明：
??a）信息安全的定义；
??b）信息安全目标或设定信息安全目标的框架；
??c）指导所有信息安全相关活动的原则；
??d）承诺满足与信息安全相关的适用要求；
??e）致力于信息安全管理体系的持续改进；
??f）将信息安全管理的职责指派给规定的角色；
??g）处理豁免和例外的程序。
对信息安全策略的任何更改应经最高管理层批准。
在较低层次上，根据需要，信息安全策略应得到专题策略的支持，以进一步授权实施信息安全控制措施。专题策略通常旨在满足组织内特定目标群体的需求，或者涵盖特定的安全领域。专题策略应与组织的信息安全策略保持一致并对其起到补充作用。
此类主题的示例包括：
??a）访问控制；
??b）物理和环境安全；
??c）资产管理；
??d）信息传递；
??e）用户终端设备的安全配置和处理；
??f）网络安全；
??g）信息安全事件管理；
??h）备份；
??i）密码术和密钥管理；
??j）信息分类和处理；
??k）技术漏洞的管理；
??l）安全开发。
应根据相关人员的适当权限和技术能力，指派制定、评审和批准专题策略的责任。评审应包括评估改进组织信息安全策略和专题策略的机会，并管理信息安全以应对以下变化：
??a）组织的业务战略；
??b）组织的技术环境；
??c）法规、法令、法律和合同；
??d）信息安全风险；
??e）当前和预计的信息安全威胁环境；
??f）从信息安全事件和事故中吸取的教训。
信息安全策略和专题策略的评审应考虑管理评审和审计的结果。当一项策略发生变化时，应考虑对其他相关策略进行评审和更新，以保持一致性。
信息安全策略和专题策略应以相关的、可访问的和目标读者可理解的形式传达给相关人员和相关方。应要求策略的接受者承认他们理解并同意遵守适用的策略。组织可以确定满足组织需要的这些策略文件的格式和名称。在一些组织中，信息安全策略和特定于主题的策略可以放在一个文档中。组织可以将这些专题策略命名为标准、指令、策略或其他。
如果信息安全策略或任何专题策略在组织外分发，应注意不要不当披露机密信息。
表1说明了信息安全策略和专题策略之间的区别。
表1 ——信息安全策略和专题策略之间的差异
| 信息安全策略 | 专题策略 | |
|---|---|---|
| 细节层次 | 一般或高级 | 具体而详细 |
| 文件化和正式批准人 | 最高管理层 | 适当的管理层级 |
其他信息
专题策略可能因组织而异。
5.2 信息安全角色和职责
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #治理 | #治理与生态系统 #保护 #韧性 |
控制
应根据组织需求定义和分配信息安全角色和职责。
目的
为组织内信息安全的实施、运营和管理建立一个定义明确、得到批准和理解的结构。
指南
应根据信息安全策略和专题策略分配信息安全角色和职责（参见5.1）。组织应当定义和管理以下方面的职责：
??a）保护信息和其他相关资产；
??b）执行特定的信息安全流程；
??c）信息安全风险管理活动，特别是对残余风险的接受（例如对风险所有人）。
??d）使用组织信息和其他相关资产的所有人员。
必要时，应对这些职责进行补充，为特定站点和信息处理设施提供更详细的指导。被分配了信息安全职责的个人可以将安全任务指派给其他人，但是他们仍须担责，并且应该确定任何委派的任务都已正确执行。
应定义、记录和沟通个人负责的每个安全领域。应该定义和记录授权级别。担任特定信息安全角色的个人应具备该角色所需的知识和技能，并应得到支持以跟上与该角色相关的发展，以及履行该角色职责所需的发展。
其他信息
许多组织任命一名信息安全管理人员，全面负责信息安全的开发和实施，并支持风险识别和缓解控制措施。
然而，配置资源和实施控制的责任通常由各个管理人员分别承担。一种常见的做法是为每项资产指定一名所有者，由其负责该资产的日常保护。
根据组织的规模和资源配置，信息安全可以由除现有角色之外的专门角色或职责来负责。
5.3 职责分离
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #治理 #身份和访问管理 | #治理与生态系统 |
控制
相互冲突的职责和相互冲突的责任领域应该被分离。
目的
降低欺诈、出错和绕过信息安全控制的风险。
指南
职责和责任领域的分离旨在分离不同个人之间的职责冲突，以防止一个人独自执行潜在冲突的职责。
组织应该确定哪些职责和责任范围需要分离。以下是可能需要隔离的活动示例：
??a）发起、批准和执行变更；
??b）请求、批准和实施访问权限；
??c）设计、实施和审查代码；
??d）开发软件和管理生产系统；
??e）使用和管理应用程序；
??f）使用应用程序和管理数据库；
??g）设计、审计和确保信息安全控制。
在设计隔离控制时，应考虑共谋的可能性。小型组织可能会发现职责分离很难实现，但应尽可能和切实可行地应用这一原则。当难以分离时，应考虑其他控制措施，如活动监控、审计跟踪和管理监督。
使用基于角色的访问控制系统时应小心谨慎，以确保人员不会被授予冲突的角色。当组织有大量的角色时，应该考虑使用自动化工具来识别冲突并促进冲突的消除。应该仔细定义和设置角色，以便在删除或重新分配角色时最大限度减少权限问题。
其他信息
没有其他信息。
5.4 管理层责任
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #治理 | #治理与生态系统 |
控制
管理层应要求所有人员根据组织的既定信息安全策略、专题策略和程序来应用信息安全。
目的
确保管理层了解其在信息安全中的角色，并采取措施确保所有人员了解并履行其信息安全职责。
指南
管理层应对信息安全策略、专题策略、程序和信息安全控制措施提供可证实的支持。
管理层责任应包括确保人员：
??a）在被授权访问组织的信息和其他相关资产之前，已正确了解其信息安全角色和职责；
??b）获得了指南，规定了他们在组织内的角色的信息安全要求；
??c）被授权履行组织的信息安全策略和专题策略；
??d）信息安全意识达到与其在组织内的角色和职责相匹配的水平 （参见6.3）；
??e）遵守雇佣、合同或协议的条款和条件，包括组织的信息安全策略和适当的工作方法；
??f）通过专业继续教育持续拥有适当的信息安全技能和资格；
??g）在可行的情况下，为报告违反信息安全策略、专题信息安全策略或程序的行为（“举报”）提供保密渠道。这可以是允许匿名举报，或者有预置措施确保只有需要处理此类举报的人才知晓举报人身份；
??h）为实施组织的安全相关流程和控制提供充足的资源和项目规划时间。
其他信息
没有其他信息。
5.5 与职能机构的联系
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #保护 #响应 #恢复 | #治理 | #防御 #韧性 |
控制
组织应当与相关职能机构建立并保持联系。
目的
确保组织与相关法律、监管和监督机构之间在信息安全方面有适当的信息沟通。
指南
组织应指定何时联系职能部门（如执法机关、监管部门、监督机构）以及由谁联系，以及如何及时报告已发现的信息安全事件。
还应利用与职能机构的联系来促进对这些职能机构当前和未来的期望的理解（例如适用的信息安全法规）。
其他信息
受到攻击的组织可以请求职能机构对攻击源采取行动。
维护此类联系可能是支持信息安全事件管理（参见5.24至5.28）或应急计划和业务连续性流程（参见5.29和5.30）的一项要求。与监管机构的联系也有助于预测和准备影响组织的相关法律或法规即将发生的变化。与其他机构的联系包括公用事业、应急服务、电力供应商以及健康和安全部门 [如消防部门（与业务连续性相关）、电信提供商（与线路路由和可用性相关）和水供应商（与设备冷却设施相关）] 。
5.6 与特定相关方的联系
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 #恢复 | #治理 | #防御 |
控制
组织应与特定相关方或其他专业安全论坛、专业协会建立并保持联系。
目的
确保在信息安全方面有适当的信息沟通。
指南
应把特定的相关方或论坛中的成员关系视作一种手段，用来
??a）增进对最佳实践的了解，并掌握最新的相关安全信息；
??b）确保对信息安全环境的了解是最新的；
??c）接收与攻击和漏洞相关的预警、建议和补丁；
??d）获得专家信息安全建议；
??e）分享和交流有关新技术、产品、服务、威胁或漏洞的信息；
??f）在处理信息安全事件时提供合适的联系人（参见5.24至5.28）。
其他信息
没有其他信息。
5.7 威胁情报
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #检测 #响应 | #威胁和漏洞能力管理 | #防御 #韧性 |
控制
应收集并分析与信息安全威胁相关的信息，以产生威胁情报。
目的
提供组织威胁环境的意识，以便采取适当的缓解措施。
指南
收集和分析关于现有或新出现的威胁的信息，以便：
??a）促进对行动的知情，以防止威胁对组织造成伤害；
??b）降低威胁的影响。
威胁情报可分为三个层次：
??a）战略威胁情报：交换关于不断变化的威胁形势的高级别信息（例如攻击者的类型或攻击的类型）；
??b）战术威胁情报：关于攻击者方法、工具和相关技术的信息；
??c）作战威胁情报：关于特定攻击的详细信息，包括技术指标。
以上三个层次的威胁情报都应该被顾及。
威胁情报应该是：
??a）相关的（即与保护本组织相关）；
??b）有洞察力的（即向组织提供对威胁形势的准确而详细的了解）；
??c）上下文的，提供情境意识（即根据事件发生的时间、地点、以前的经验和在类似组织中的流行程度为信息添加上下文）；
??d）可操作的（即组织可以快速有效地对信息采取行动）。
威胁情报活动应包括：
??a）建立生产威胁情报的目标；
??b）确定、审查和选择必要和适当的内部和外部信息来源，以提供生产威胁情报所需的信息；
??c）从选定的内部和外部来源收集信息；
??d）处理收集的信息，为分析做准备（例如翻译、格式化或确证信息）；
??e）分析信息，了解它与组织的关系以及对组织的意义；
??f）以可理解的形式与相关个人交流和分享。
应对威胁情报进行分析，并在以后使用：
??a）通过实施流程，将从威胁情报来源收集的信息纳入组织的信息安全风险管理流程；
??b）作为防火墙、入侵检测系统或反恶意软件解决方案等技术预防和检测控制的附加输入；
??c）作为信息安全测试流程和技术的输入。
组织应在互利合作的基础上与其他组织共享威胁情报，以改进整体威胁情报。
其他信息
组织可以使用威胁情报来预防、检测或响应威胁。组织可以生成威胁情报，但更常见的是接收和利用其他来源生成的威胁情报。
5.8 项目管理中的信息安全
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #治理 | #治理与生态系统 #保护 |
控制
项目管理中应纳入信息安全。
目的
贯穿整个项目生命周期，确保在在项目管理中有效解决与项目和可交付成果相关的信息安全风险。
指南
应将信息安全集成到项目管理中，以确保信息安全风险作为项目管理的一部分得到解决。这可适用于任何类型的项目，无论其复杂程度、规模、持续时间、学科或应用领域如何（如核心业务流程、ICT、设施管理或其他支持流程的项目）。
正在执行的项目管理中应要求：
??a）在整个项目生命周期中，信息安全风险作为项目风险的一部分，在早期阶段定期得到评估和处理；
??b）信息安全要求 [如应用安全要求（8.26）、遵守知识产权的要求（5.32）等。] 在项目的早期阶段得到解决；
??c）在整个项目生命周期中，考虑和处理与项目执行相关的信息安全风险，如内部和外部通信方面的安全；
??d）审查信息安全风险处理的进展，并评估和测试处理的有效性。
应由合适的人员或治理机构（如项目指导委员会）在预定义的阶段持续核查信息安全考虑因素和活动的适当性。
应定义与项目相关的信息安全责任和权限，并分配给指定的角色。
应使用各种方法确定项目交付的产品或服务的信息安全要求，包括从信息安全策略、专题策略和法规中得出合规性要求。进一步的信息安全要求可以从威胁建模、事件审查、使用漏洞阈值或应急计划等活动中得出，从而确保信息系统的体系结构和设计能够抵御基于运营环境的已知威胁。
应该为所有类型的项目确定信息安全要求，而不仅仅是ICT开发项目。确定这些要求时，还应顾及以下因素：
??a）涉及哪些信息（信息判定），对应的信息安全需求有哪些（分类；参见5.12）以及缺乏足够的安全性可能导致的潜在负面业务影响。
??b）所涉信息和其他相关资产的必要保护需求，特别是在保密性、完整性和可用性方面；
??c）为了得出身份鉴别要求，对所声称的实体身份所需的信任或保证级别；
??d）为客户和其他潜在业务用户以及特权或技术用户（如相关项目成员、潜在运营人员或外部供应商）提供访问和授权流程；
??e）告知用户他们的义务和责任；
??f）源自业务流程的需求，如交易记录和监控、不可否认性需求；
??g）其他信息安全控制措施规定的要求（如记录和监控或数据泄漏检测系统的接口）；
??h）遵守组织运作的法律、法规、规章和合同环境；
??i）第三方满足组织的信息安全策略和专题策略（包括任何协议或合同中的相关安全条款）所需的信心或保证级别。
其他信息
项目开发方法，如瀑布生命周期或敏捷生命周期，应该以结构化的方式支持信息安全，可以根据项目的特征进行调整，以适应评估信息安全风险的严重程度的要求。应尽早考虑产品或服务的信息安全要求（例如在规划和设计阶段），这样可以为质量和信息安全提供更有效、更具成本效益的解决方案。ISO 21500和ISO 21502就项目管理的概念和过程提供了指南，这些概念和过程对于项目的绩效非常重要。
ISO/IEC 27005提供了有关使用风险管理流程来确定控制措施以满足信息安全要求的指南。
5.9 信息和其他相关资产的清单
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #资产管理 | #治理与生态系统 #保护 |
控制
应开发和维护信息和其他相关资产（包括所有者）的清单。
目的
识别组织的信息和其他相关资产，以保护其信息安全并分配适当的所有权。
指南
清单
组织应确定其信息和其他相关资产，并确定它们在信息安全方面的重要性。文件应酌情保存在专用或现有的清单中。
信息和其他相关资产的清单应准确、最新、一致，并与其他清单保持一致。确保信息和其他相关资产清单准确性的选项包括：
??a）根据资产清单定期审查已识别的信息和其他相关资产；
??b）在安装、更改或删除资产的过程中自动执行清单更新。
资产的位置应适当地包括在清单中。
清单不必是信息和其他相关资产的单一列表。考虑到清单应由相关职能部门维护，因此可将其视为一组动态清单，如信息资产、硬件、软件、虚拟机、设施、人员、能力、功能和记录的清单。
应根据与资产相关的信息分类（参见5.12）对每项资产进行分类。
信息和其他相关资产清单的粒度应符合组织的需求。有时，由于资产的性质，信息生命周期中资产的特定实例不适合记录。短期资产的一个例子是生命周期可能很短的VM实例。
所有权
对于已识别的信息和其他相关资产，资产的所有权应分配给个人或团体，并应识别其分类（参见5.12、5.13）。应实施确保及时分配资产所有权的流程。当创建资产或将资产转移到组织时，应分配所有权。当当前资产所有者离开或改变工作角色时，应根据需要重新分配资产所有权。
所有者职责
资产所有者应负责在整个资产生命周期内对资产进行适当管理，确保：
??a）对信息和其他相关资产进行编目；
??b）信息和其他相关资产得到适当的分类和保护；
??c）定期审查分类；
??d）列出并链接支持技术资产的组件，如数据库、存储、软件组件和子组件；
??e）建立了信息和其他相关资产的可接受的使用要求（参见5.10）；
??f）访问限制符合分类，并且是有效的，并定期审查；
??g）删除或处置信息和其他相关资产时，以安全的方式进行处理，并从清单中删除；
??h）他们参与识别和管理与其资产相关的风险；
??i）他们支持承担管理其信息的角色和责任的人员。
其他信息
信息和其他相关资产的清单通常是确保有效保护信息所必需的，也可能出于其他目的，如健康和安全、保险或财务原因。信息和其他相关资产的清单还支持风险管理、审计活动、漏洞管理、事件响应和恢复计划。
任务和责任可以委派（例如，委派给负责日常资产的保管人），但委派的人或团队仍然有责任。
指定共同提供特定服务的信息集合和其他相关资产是很有用的。在这种情况下，这些服务的所有者负责服务的交付，包括其资产的操作。
有关信息技术（IT）资产管理的更多信息，请参见ISO/IEC 19770-1。有关资产管理的更多信息，请参见ISO 55001。
5.10 信息和其他相关资产的可接受的使用
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 #信息保护 | #治理与生态系统 #保护 |
控制
应确定、记录和实施处理信息和其他相关资产的可接受的使用规则和程序。
目的
确保信息和其他相关资产得到适当的保护、使用和处理。
指南
对使用或有权访问组织信息和其他相关资产的所有人员，包括外部用户，应令其知晓保护和处理组织信息和其他相关资产的信息安全要求。他们应对自己使用的任何信息处理设施负责。
组织应就信息和其他相关资产的可接受的使用建立专题策略，并将其传达给使用或处理信息和其他相关资产的任何人。关于可接受的使用的专题策略应该为个人如何使用信息和其他相关资产提供明确的指南。专题策略应说明：
??a）从信息安全的角度看，个人的期望的和不可接受的行为；
??b）对信息和其他相关资产的允许或禁止使用；
??c）组织实施的监控活动。
应根据信息的分类（参见5.12）和确定的风险，为整个信息生命周期制定可接受的使用程序。应顾及以下事项：
??a）支持每个分类级别的保护要求的访问限制；
??b）维护信息和其他相关资产的授权用户记录；
??c）对信息的临时或永久拷贝的保护水平与对原始信息的保护水平一致；
??d）根据制造商的规范存储与信息相关的资产（参见7.8）；
??e）清晰标记存储介质（电子或物理）的所有副本，以引起授权接收者的注意（参见7.10）；
??f）作废信息和其他相关资产的授权以及支持的删除方法（参见8.10）。
其他信息
可能出现相关资产不直接属于组织的情况，例如公共云服务。此类第三方资产以及与此类外部资产（如信息、软件）相关联的任何组织资产的使用应被确定为适用并受到控制，例如通过与云服务提供商签订协议。当使用协作工作环境时，也应该谨慎。
5.11 资产返还
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 | #保护 |
控制
员工和其他相关方在变更或终止其雇佣关系、合同或协议时，应归还其拥有的所有组织资产。
目的
在变更或终止雇佣关系、合同或协议的过程中保护组织的资产。
指南
应正式发布雇佣变更或终止流程，以包括归还本组织拥有或委托给本组织的所有先前发放的实物和电子资产。
如果相关人员和其他相关方买下组织的设备或原本是使用他们自己的个人设备，应遵循相应的程序，确保所有相关信息被追溯并转移到组织，并从设备中安全地删除（参见7.14）。
如果相关人员和其他相关方掌握对继续运行至关重要的知识，该信息应形成文件并传递给组织。
在通知期间及之后，组织应防止收到雇佣终止通知的人员未经授权复制相关信息（例如知识产权）。
组织应明确标识和记录要归还的所有信息和其他相关资产，其中可能包括：
??a）用户终端设备；
??b）便携式存储设备；
??c）专业设备；
??d）信息系统、站点和物理档案的身份鉴别硬件（例如机械钥匙、物理令牌和智能卡）；
??e）信息的物理副本。
其他信息
如果信息存在于不归组织所拥有的资产中，将很难索回。在这种情况下，有必要使用其他信息安全控制措施来限制信息的使用，如访问权限管理（5.18）或加密技术的使用（8.24）。
5.12 信息分类
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #信息保护 | #保护 #防御 |
控制
应根据组织的信息安全需求，基于机密性、完整性、可用性和利益相关方的要求，对信息进行分类。
目的
根据信息对组织的重要性，确保识别和理解信息的保护需求。
指南
组织应建立关于信息分类的专题策略，并将其传达给所有利益相关方。
组织应当考虑分类方案中的机密性、完整性和可用性要求。
信息的分类和相关保护控制措施应考虑共享或限制信息、保护信息完整性和确保可用性的业务需求，以及有关信息机密性、完整性或可用性的法律要求。除了信息之外的资产也可以按照其存储的、处理的或者掌控或保护的信息的分类来分类。
信息的所有者应对其分类负责。
分类方案应包括分类惯例和随着时间的推移对分类进行审查的标准。分类结果应根据信息在其生命周期中的价值、敏感性和重要性的变化进行更新。
该方案应符合关于访问控制的专题策略（参见5.1），并应能够满足组织的特定业务需求。
分类可以根据信息泄露对组织的影响程度来确定。方案中定义的每个级别都应该有一个在分类方案应用环境中有意义的名称。
分类方案应该在整个组织中保持一致，并包含在其程序中，以便每个人都以相同的方式对信息和适用的其他相关资产进行分类。通过这种方式，每个人都对保护要求有共同的理解，并应用适当的保护。
组织内使用的分类方案可以不同于其他组织使用的方案，即使级别的名称相似。此外，在组织之间移动的信息在分类上可能有所不同，这取决于它在每个组织中的上下文，即使它们的分类方案是相同的。因此，与其他组织签订的包含信息共享的协议应包括识别信息分类和解释其他组织的分类级别的程序。通过寻找相关处理和保护方法的等效性，可以确定不同方案之间的一致性。
其他信息
分类为处理信息的人提供了如何处理和保护信息的简明指示。创建具有相似保护需求的信息集合并指定适用于每个集合中所有信息的信息安全程序有助于实现这一点。这种方法减少了逐一进行风险评估和定制控制设计的需要。
经过一段时间后，信息可能不再敏感或重要。例如，当信息公开后，它就不再有机密性要求，但仍然需要保护其完整性和可用性。应考虑这些方面，因为过度分类可能导致实施不必要的控制措施，从而导致额外的费用；或者相反的，分类不足可能导致控制措施不足以保护信息不被泄露。
例如，信息机密性分类方案可以基于以下四个级别，如下所示：
??a）泄露不会造成伤害；
??b）泄露会造成轻微的声誉损害或轻微的运营影响；
??c）泄露对运营或业务目标有重大的短期影响；
??d）泄露会对长期业务目标产生严重影响，或使组织的生存面临风险。
5.13 信息标签
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #信息保护 | #保护 #防御 |
控制
应当根据组织采用的信息分类方案，制定并实施一套适当的信息标签程序。
目的
促进信息分类的交流，支持信息处理和管理的自动化。
指南
信息标签程序应涵盖所有格式的信息和其他相关资产。标签应反映5.12中建立的分类方案。标签应容易辨识。考虑到如何根据存储介质的类型访问信息或处理资产，这些程序应就标签的粘贴位置和方式提供指南。这些程序可以定义：
??a）省略标记的情况（例如略过标记非机密信息以减少工作量）；
??b）如何标记通过电子或物理方式或任何其他格式发送或存储的信息；
??c）如何处理无法标签的情况（例如，由于技术限制）。
标签技术的例子包括：
??a）物理标签；
??b）页眉和页脚；
??c）元数据；
??d）水印；
??e）橡皮图章。
数字信息应利用元数据来识别、管理和控制信息，特别是在保密性方面。元数据还应支持高效和正确的信息搜索，便于系统根据相关的分类标签进行交互和决策。
这些程序应说明如何根据组织的信息模型和ICT架构，将元数据附加到信息上，使用什么标签，以及如何处理数据。
系统在处理信息时，应根据信息的安全属性添加额外的相关元数据。
应使员工和其他相关方了解标签程序。应向所有人员提供必要的培训，以确保正确标记信息并进行相应的处理。
包含敏感或关键信息的系统的输出应带有适当的分类标签。
其他信息
分类信息的标签是信息共享的一个关键要求。
可以附加到信息的其他有效元数据是——哪个组织过程、在什么时间创建了该信息。
信息和其他相关资产的标签有时会产生负面影响。恶意人员可以更容易地识别机密资产从而更容易导致潜在的滥用。
有些系统不在单个文件或数据库记录上标注它们的分类，而是以包含或允许包含的任何信息的最高分类级别来保护所有信息。在这种系统中，通常在导出信息时确定并标记信息。
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）考虑如何反映与动态访问控制相关的元素或因素。
其他信息
在访问控制的上下文中，通常会用到一些支配性的原则。两个最常用的原则是：
??a）按需所知：一个实体只被授权访问该实体执行其任务所需的信息（不同的任务或角色意味着不同的必需信息，因此有不同的访问权限）；
??b）按需使用：一个实体只有在存在明确需求的情况下才被分配访问信息技术基础设施的权限。
在指定访问控制规则时，应注意顾及：
??a）以最小特权为前提建立规则，“未经明确允许，则一律禁止”，而不是更弱的规则“未经明确禁止，一律允许”；
??b）由信息处理设施自动发起和由用户自行决定发起的信息标签的变化（参见5.13）；
??c）由信息系统自动发起和由管理员发起的用户权限变更；
??d）何时定义规则和定期审查对规则的批准。
访问控制规则应由书面程序（参见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）不同的服务和系统不使用相同的口令；
??e）遵守这些规则的义务也包含在雇佣条款和条件中（参见6.2）.
口令管理系统
当口令用作身份验证信息时，口令管理系统应该：
??a）允许用户选择和更改自己的口令，并包括一个确认程序，以解决输入错误；
??b）根据“用户责任”中的良好实践建议 [参见c] 实施强口令；
??c）强制用户在首次登录时更改口令；
??d）必要时强制更改口令，例如在发生安全事故后，或者在雇佣关系终止或变更时，如果用户知道保持活动状态的身份（例如共享身份）的口令；
??e）防止重复使用以前的口令；
??f）防止使用已被攻陷系统的常用口令和已受侵害的用户名、口令组合；
??g）输入口令时不在屏幕上显示口令；
??h）以受保护的形式存储和传输口令。
应根据批准的口令加密技术对口令进行加密和哈希处理（参见8.24）。
其他信息
口令是一种常用的身份验证信息，也是验证用户身份的常用方法。其他类型的鉴别信息是密钥、存储在硬件令牌（例如智能卡）上的数据，这些硬件令牌产生鉴别代码和生物特征数据，例如虹膜扫描或指纹。更多信息可在ISO/IEC 24760系列中找到。
要求频繁更改口令可能不妥，因为用户可能会对频繁的更改感到厌烦，或忘记新口令，或将它们记在不安全的地方，或选择不安全的口令等。提供单点登录（SSO）或其他身份鉴别管理工具（如口令仓库）可以减少用户需要保护的身份鉴别信息量，从而提高这种控制的有效性。但是，这些工具也会增加身份鉴别信息泄露的影响。
一些应用程序要求用户口令由独立机构分配。在这种情况下，“口令管理系统”的c）和d）不适用。
5.18 访问权限
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
控制
应根据组织关于访问控制的专题策略和规则来提供、审查、修改和删除对信息和其他相关资产的访问权限。
目的
确保根据业务要求定义和授权对信息和其他相关资产的访问。
指南
访问权限的提供和撤销
分配或撤销授予实体已验证身份的物理和逻辑访问权限的配置过程应包括：
??a）从信息和其他相关资产的所有者处获得使用信息和其他相关资产的授权（参见5.9）；由管理层单独批准访问权限也是合适的；
??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）供应商或内包变更情况下的信息可移植性；
?????? 6）记录管理；
??????7）资产的返还；
??????8）安全处置信息和其他相关资产；
??????9）持续的保密要求；
??n）对供应商人员和设施的人身安全和物理安全的预期水平。
应考虑在供应商变得无法提供其产品或服务的情况下（如由于事故、供应商不再经营、或由于技术进步不再提供某些组件）继续信息处理的程序，以避免在安排替代产品或服务时的任何延迟（例如，提前确定替代供应商或始终使用替代供应商）。
其他信息
当组织不可能对供应方提出要求时，组织应该：
??a）在决定选择供应商及其产品或服务时，考虑本控制中给出的指南；
??b）根据风险评估实施必要的补偿控制。
信息安全管理不足的供应商可能会将信息置于风险之中。应确定并应用控制措施来管理供应商对信息和其他相关资产的访问。例如，如果有对信息保密的特殊需要，可以使用保密协议或加密技术。另一个例子是当供应商协议涉及跨境信息传递或访问时的个人数据保护风险。组织需要意识到保护信息的法律或合同责任仍由组织承担。
供应商提供的ICT基础设施组件或服务控制不当也可能导致风险。故障或易受攻击的组件或服务可能会导致组织或其他实体的信息安全违背（例如，它们可能会导致恶意软件感染、攻击或对组织以外的实体造成其他伤害）。
更多细节见ISO/IEC 27036-2。
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/IEC 27036系列。有关云服务协议，请参见ISO/IEC 19086系列。
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/IEC 27036-3。
软件识别（SWID）标签还可以通过提供关于软件来源的信息来帮助实现供应链中更好的信息安全。更多详情见ISO/IEC 19770-2。
5.22 供应商服务的监控、审查和变更管理
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #供应商关系安全 #信息安全保证 | #治理与生态系统 #保护 #防御 |
控制
组织应当定期监视、评审、评估和管理供方信息安全实践和服务提供方面的变化。
目的
根据供应商协议，维护商定的信息安全和服务交付水平。
指南
供应商服务的监控、审查和变更管理应确保符合协议的信息安全条款和条件，信息安全事件和问题得到适当管理，并且供应商服务或业务状态的变化不会影响服务交付。
这应当包括管理组织与供应商之间关系的过程，以便：
??a）监控服务性能水平，以验证是否符合协议；
??b）监控供应商做出的变更，包括：
??????1）增强当前提供的服务；
??????2）任何新应用和系统的开发；
??????3）供应商策略和程序的修改或更新；
??????4）解决信息安全事故和提高信息安全的新的或变更的控制措施；
??c）监控供应商服务的变化，包括：
??????1）网络的改变和增强；
??????2）新技术的使用；
??????3）采用新产品或更新版本或发行版；
??????4）新的开发工具和环境；
??????5）服务设施物理位置的变化；
??????6）下级供应商的变更；
??????7）分包给另一个供应商；
??d）审查供应商提供的服务报告，并根据协议要求安排定期进度会议；
??c）对供应商和次级供应商进行审计，同时审查独立审计师的报告（如果有的话），并跟进发现的问题；
??e）提供有关信息安全事件的信息，并根据协议以及任何支持性指南和程序的要求审查这些信息；
??f）审查供应商审计记录和信息安全事件、运营问题、故障的记录，跟踪与交付的服务相关的故障和中断；
??g）响应和管理任何确定的信息安全事件或事故；
??h）识别信息安全漏洞并进行管理；
??i）审查供应商与其自身供应商关系方面的信息安全；
??j）确保供应商保持满足需要的服务能力以及可行的计划，以确保在重大服务故障或灾难后能保持约定的服务连续性水平（参见5.29、5.30、5.35、5.36、8.14）；
??k）确保供应商指派审查合规性和执行协议要求的责任；
??l）定期评估供应商保持足够的信息安全水平。
??m）管理供应商关系的责任应分配给指定的个人或团队。应提供足够的技术技能和资源，以监测协议的要求，特别是信息安全要求是否得到满足。当发现服务提供中的不足之处时，应采取适当的措施。
其他信息
更多细节见ISO/IEC 27036-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/IEC 17788、ISO/IEC 17789和ISO/IEC 22123-1找到。与支持退出策略的云可移植性相关的细节可以在ISO/IEC 19941中找到。ISO/IEC 27017中描述了与信息安全和公共云服务相关的细节。在ISO/IEC 27018中描述了与充当PII处理器的公共云中的PII保护相关的细节。云服务的供应商关系由ISO/IEC 27036-4和云服务协议涵盖，其内容由ISO/IEC 19086系列处理，安全和隐私由ISO/IEC 19086-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）创建事故报告。
在实施事故管理程序时，应考虑在规定的时间范围内向相关利益方报告事故的任何外部要求（例如向监管机构报告违规的要求）。
其他信息
信息安全事故可能超越组织和国家的界限。为了响应此类事故，适当地协调响应并与外部组织共享关于这些事故的信息是有益的。
ISO/IEC 27035中提供了有关信息安全事故管理的一系列详细指南
5.25 信息安全事件的评估和决策
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #检测性 | #保密性 #完整性 #可用性 | #检测 #响应 | #信息安全事件管理 | #防御 |
控制
组织应评估信息安全事件，并决定是否将其归类为信息安全事故。
目的
确保信息安全事件的有效分类和优先排序。
指南
应商定信息安全事件的分类和优先级框架，以确定事件的后果和优先级。该框架应包括将事件归类为信息安全事件的标准。联系人应使用商定的方案评估每个信息安全事件。
负责协调和响应信息安全事件的人员应执行评估并对信息安全事件做出决策。
评估和决策的结果应详细记录，以便将来参考和验证。
其他信息
ISO/IEC 27035系列提供了关于事故管理的进一步的指南。
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #纠正性 | #保密性 #完整性 #可用性 | #响应 #恢复 | #信息安全事件管理 | #防御 |
5.26 应对信息安全事故
控制
应根据记录的程序应对信息安全事故。
目的
确保对信息安全事故做出高效和有效的响应。
指南
组织应建立有关信息安全事故响应的程序，并向所有相关利益方传达这些程序。
信息安全事故应由具备所需能力的指定团队来响应（参见5.24）。
响应应包括以下内容：
??a）如果事故的后果可能扩散，控制受事故影响的系统；
??b）事故发生后尽快收集证据（参见5.28）；
??c）升级，根据需要包括危机管理活动和可能调用业务连续性计划（参见5.29和5.30）。
??d）确保所有涉及的响应活动都被正确记录，以供以后分析；
??e）遵循按需所知原则，向所有相关的内部和外部利益方传达信息安全事件的存在或任何相关细节；
??f）与职能机构、外部利益团体和论坛、供应商和客户等内部和外部各方协调，以提高响应的有效性，并帮助将对其他组织的影响降至最低；
??g）一旦事故得到成功解决，正式结案并记录；
??h）根据需要进行信息安全取证分析（参见5.28）。
??i）执行事故后分析以确定根本原因。确保按照规定的程序进行记录和沟通（参见5.27）；
??j）识别和管理信息安全漏洞和弱点，包括与导致、促成或未能防止事故的控制措施相关的漏洞和弱点。
其他信息
ISO/IEC 27035系列提供了关于事故管理的进一步的指南。
5.27 从信息安全事故中吸取教训
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #信息安全事件管理 | #防御 |
控制
从信息安全事故中获得的知识应用于加强和改进信息安全控制。
目的
降低未来事故发生的可能性或后果。
指南
组织应建立量化和监控信息安全事故的类型、数量和成本的程序。
从信息安全事故评估中获得的信息应用于：
??a）加强事故管理计划，包括事故情景和程序（参见5.24）；
??b）确定重复发生或严重的事故及其原因，以更新组织的信息安全风险评估，并确定和实施必要的额外控制措施，以降低未来类似事故发生的可能性或后果。实现这一目标的机制包括收集、量化和监测有关事故类型、数量和成本的信息；
??c）通过举例说明可能发生的情况、如何应对此类事件以及如何在未来避免此类事件，增强用户意识和培训（参见6.3）。
其他信息
ISO/IEC 27035系列提供了进一步的指南。
5.28 收集证据
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #纠正性 | #保密性 #完整性 #可用性 | #检测 #响应 | #信息安全事件管理 | #防御 |
控制
组织应建立并实施识别、收集、获取和保存信息安全事件相关证据的程序。
目的
确保一致和有效地管理与信息安全事故相关的证据，以便采取纪律和法律行动。
指南
在出于纪律和法律行动的目的处理与信息安全事件相关的证据时，应制定并遵循内部程序。应考虑不同管辖区的要求，以最大限度地提高相关管辖区的准入机会。
一般而言，这些证据管理程序应根据不同类型的存储介质、设备和设备状态（即开机或关机）提供证据识别、收集、获取和保存的说明。通常需要以适当的国家法院或其他纪律论坛可以接受的方式收集证据。应该可以证明：
??a）记录完整且未被篡改；
??b）电子证据的副本几乎肯定与原件完全相同；
??c）在记录证据时，收集证据的任何信息系统都在正常运行。
在可能的情况下，应寻求人员和工具的认证或其他相关资格手段，以增强所保存证据的价值。
数字证据可以超越组织或司法界限。在这种情况下，应确保组织有权收集所需的信息作为数字证据。
其他信息
当首次检测到信息安全事件时，该事件是否会导致法院诉讼并不总是显而易见的。因此，在意识到事故的严重性之前，存在着必要的证据被有意或无意销毁的危险。建议在任何预期的法律行动中尽早征求法律意见或执法部门的意见，并就所需的证据征求意见。
ISO/IEC 27037为数字证据的识别、收集、获取和保存提供了定义和指南。
ISO/IEC 27050系列处理电子发现，包括处理作为证据的电子存储信息。
5.29 中断期间的信息安全
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 | #连续性 | #保护 #韧性 |
控制
组织应规划如何在中断期间将信息安全保持在适当的级别。
目的
在中断期间保护信息和其他相关资产。
指南
组织应确定在中断期间调整信息安全控制的要求。信息安全要求应包括在业务连续性管理流程中。
应制定、实施、测试、审查和评估计划，以在中断或故障后维护或恢复关键业务流程的信息安全。信息的安全性应该在要求的时间范围内恢复到要求的级别。
组织应当实施并保持：
??a）业务连续性和ICT连续性计划中的信息安全控制、支持系统和工具；
??b）中断期间维护现有信息安全控制的流程；
??c）对中断期间无法维持的信息安全控制实施补偿控制。
其他信息
在业务连续性和ICT连续性规划方面，可能有必要根据与正常运行条件相比的中断类型来调整信息安全要求。作为在业务连续性管理中执行的业务影响分析和风险评估的一部分，除了维护可用性的需要之外，还应考虑失去信息机密性和完整性的后果并确定其优先级。
关于业务连续性管理系统的信息可以在ISO 22301和ISO 22313找到。有关业务影响分析（BIA）的进一步的指南可在ISO/TS 22317中找到。
5.30 ICT为业务连续性做好准备
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #纠正性 | #可用性 | #响应 | #连续性 | #韧性 |
控制
应根据业务连续性目标和ICT连续性要求，规划、实施、维护和测试ICT准备情况。
目的
确保组织的信息和其他相关资产在中断情况下可用。
指南
ICT为业务连续性做好准备是业务连续性管理和信息安全管理的一个重要组成部分，以确保在中断期间能够继续实现本组织的目标。
ICT连续性要求是业务影响分析（BIA系统）的结果。BIA流程应使用影响类型和标准来评估交付产品和服务的业务活动中断所造成的长期影响。应使用由此产生的影响的大小和持续时间来确定应分配恢复时间目标（RTO）的优先活动。然后，BIA应确定需要哪些资源来支持优先活动。还应该为这些资源指定RTO。这些资源的一个子集应包括ICT服务。
涉及ICT服务的BIA可以扩展到定义ICT系统的性能和容量要求，以及在中断期间支持活动所需的信息恢复点目标（RPO）。
根据涉及ICT服务的BIA和风险评估的结果，本组织应确定和选择ICT连续性战略，这些战略考虑到中断之前、期间和之后的备选方案。业务连续性策略可以包括一个或多个解决方案。在这些战略的基础上，应制定、实施和测试计划，以满足ICT服务所需的可用性水平，并在关键流程中断或出现故障后的规定时限内完成。
组织应当确保：
??a）建立适当的组织结构，在具有必要责任、授权和能力的人员支持下，准备、缓解和响应中断；
??b）ICT连续性计划，包括详细说明组织如何计划管理ICT服务中断的应对和恢复程序，包括：
??????1）通过演练和测试进行定期评估；
??????2）经管理层批准；
??c）ICT连续性计划包括以下ICT连续性信息：
??????1）满足BIA中指明的业务连续性要求和目标的性能和容量规格；
??????2）每个优先ICT服务的RTO以及恢复这些组件的程序；
??????3）被定义为信息的优先ICT资源的RPO以及恢复这些信息的程序。
其他信息
管理ICT连续性是业务连续性要求的一个关键部分，涉及可用性，以便能够：
??a）响应ICT服务中断并从中恢复，无论其原因如何；
??b）确保优先活动的连续性得到所需ICT服务的支持；
??c）在ICT服务中断发生之前，并在检测到至少一个可能导致ICT服务中断的事件时做出反应。
关于ICT为业务连续性做好准备的进一步的指南，见ISO/IEC 27031。
关于业务连续性管理系统的进一步的指南可参见ISO 22301和ISO 22313。有关BIA的进一步的指南可在ISO/TS 22317中找到。
5.31 法律、法规、监管和合同要求
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #法律与合规性 | #治理与生态系统 #保护 |
控制
应当识别、记录和更新与信息安全相关的法律、法规、监管和合同要求以及组织满足这些要求的方法。
目的
确保符合与信息安全相关的法律、法规、监管和合同要求。
指南
常规
在以下情况下，应考虑外部要求，包括法律、法规、监管或合同要求：
??a）制定信息安全策略和程序时；
??b）设计、实施或更改信息安全控制措施时；
??c）作为为内部需求或供应商协议设定信息安全要求的流程的一部分，对信息和其他相关资产进行分类时；
??d）执行信息安全风险评估并确定信息安全风险处理活动时；
??e）确定与信息安全相关的流程以及相关角色和职责时；
??f）确定与组织有关的供方合同要求以及产品和服务的供应范围时。
法律和法规
本组织应当：
??a）确定与组织的信息安全相关的所有法律法规，以了解其业务类型的要求；
??b）考虑所有相关国家的合规性，如果组织：
??????— 在其他国家开展业务；
??????— 使用法律法规可能影响组织的其他国家的产品和服务；
??????— 在法律和法规可能会影响组织的地方跨辖区传递信息；
??c）定期审查已确定的立法和法规，以跟上变化并确定新的立法；
??d）定义并记录满足这些要求的具体流程和个人职责。
密码学
密码学是一个经常有特定法律要求的领域。应考虑遵守与以下项目相关的相关协议、法律和法规：
??a）对执行加密功能的计算机硬件和软件的进出口限制；
??b）限制进口或出口的设计有加密功能的计算机硬件和软件；
??c）对使用加密技术的限制；
??d）国家职能机构获取加密信息的强制性或自主性方法；
??e）数字签名、印章和证书的有效性。
建议在确保遵守相关法律法规时寻求法律建议，尤其是当加密信息或加密工具跨越管辖边界时。
合同
与信息安全相关的合同要求应包括以下内容：
??a）与客户的合同；
??b）与供应商的合同（参见5.20）；
??c）保险合同。
其他信息
没有其他信息。
5.32 知识产权
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #法律与合规性 | #治理与生态系统 |
控制
组织应当实施适当的程序来保护知识产权。
目的
确保遵守与知识产权和专有产品使用相关的法律、法规、监管和合同要求。
指南
应考虑以下指南来保护任何可被视为知识产权的材料：
??a）界定和宣传保护知识产权的专题策略；
??b）发布定义软件和信息产品合规使用的知识产权合规程序；
??c）仅通过已知和有信誉的来源获取软件，以确保版权不受侵犯；
??d）维护适当的资产登记册，并根据保护知识产权的要求识别所有资产；
??e）维护许可证、手册等所有权的证明和证据。；
??f）确保不超过许可证中允许的任何最大用户或资源数量 [例如中央处理器（CPU）] ；
??g）进行审查以确保只安装授权软件和许可产品；
??h）提供维持适当许可条件的程序；
??i）提供作废软件或将软件转让给他人的程序；
??j）遵守从公共网络和外部来源获得的软件和信息的条款和条件；
??k）除非版权法或适用的许可证允许，否则不得复制、转换为另一种格式或从商业记录（视频、音频）中提取；
??l）除非版权法或适用许可证允许，否则不得全部或部分复制标准（如ISO/IEC国际标准）、书籍、文章、报告或其他文件。
其他信息
知识产权包括软件或文档版权、设计权、商标、专利和源代码许可证。
专利软件产品通常是根据许可协议提供的，该协议规定了许可条款和条件，例如，将产品的使用限制在特定的机器上，或者将复制限制在仅创建备份拷贝上。有关IT资产管理的详细信息，请参见ISO/IEC 19770系列。
数据可以从外部来源获得。通常情况下，这些数据是根据数据共享协议或类似法律文书的条款获得的。此类数据共享协议应明确规定允许对获取的数据进行何种处理。还建议明确说明数据的出处。有关数据共享协议的详细信息，请参见ISO/IEC 23751：2022）。
法律、法规、规章和合同要求可能会对专有资料的复制施加限制。特别是，他们可能会要求只能使用由组织开发或由开发人员许可或提供给组织的材料。侵犯版权可能导致法律诉讼，包括罚款和刑事诉讼。
除了本组织需要遵守其对第三方知识产权的义务之外，还应管理人员和第三方未能维护本组织自身知识产权的风险。
5.33 记录保护
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全领域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #法律与合规性 #资产管理 #信息保护 | #防御 |
控制
应防止记录丢失、毁坏、伪造、未经授权的访问和未经授权的发布。
目的
确保符合法律、法规、监管和合同要求，以及与记录保护和可用性相关的社区或社会期望。
指南
组织应采取以下步骤来保护记录的真实性、可靠性、完整性和可用性，因为其业务环境和管理要求会随着时间的推移而变化：
??a）发布关于记录存储、保管处理链和处置的指南，包括防止篡改记录。这些指南应与组织关于记录管理的专题策略和其他记录要求保持一致；
??b）起草一份保留计划，规定记录及其保留期限。
储存和处理系统应确保记录的标识及其保存期限，同时考虑国家或地区的法律或法规，以及社区或社会的期望（如适用）。如果组织不再需要某记录，该系统应允许在该期限后对记录进行适当的销毁。
在决定保护特定组织记录时，应考虑基于组织分类方案的相应信息安全分类。记录应分类为不同的记录类型（例如，会计记录、业务交易记录、人事记录、法律记录），每种记录类型都有详细的保留期和允许的存储介质类型，可以是物理的也可以是电子的。
应选择数据存储系统，以便根据须满足的要求，在可接受的时间范围内以可接受的格式检索所需的记录。
在选择电子存储介质的情况下，应建立程序来确保在整个保留期内能够访问记录（存储介质和格式可读性），以防止因未来技术变化而造成的损失。还应保留与加密档案或数字签名相关的任何相关密钥和程序，以便在记录保留期间对记录进行解密（参见8.24）。
应根据存储介质制造商提供的建议实施存储和处理程序。应考虑用于存储记录的介质变质的可能性。
其他信息
记录记载了单个事件或交易，或者可以形成旨在记载工作流程、活动或职能的集合。它们既是业务活动的证据，也是信息资产。任何信息集，无论其结构或形式如何，都可以作为记录来管理。这包括在业务过程中创建、捕获和管理的文档形式的信息、数据集合或其他类型的数字或模拟信息。
在记录管理中，元数据是描述记录的背景、内容和结构及其长期管理的数据。元数据是任何记录的重要组成部分。
可能有必要安全地保留一些记录，以满足法律、法规、监管或合同要求，并支持重要的业务活动。国家法律或法规可以设定信息保留的时间段和数据内容。关于记录管理的更多信息可以在ISO
15489找到。
5.34 PII隐私和保护
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全领域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #信息保护 #法律与合规性 | #保护 |
控制
组织应根据适用的法律法规和合同要求，确定并满足有关PII隐私和保护的要求。
目的
确保遵守关于保护PII的信息安全方面的法律、法规、监管和合同要求。
指南
组织应制定并向所有相关利益方传达关于PII隐私和保护的专题策略。
组织应制定并实施维护PII隐私和保护的程序。这些程序应传达给参与处理个人身份信息的所有相关利益方。
遵守这些程序以及所有关于PII隐私和保护的相关法律法规需要适当的角色、职责和控制。通常，最好通过指定一名负责人（如隐私官员）来实现，该负责人应向工作人员、服务提供商和其他相关方提供有关其个人责任和应遵循的具体程序的指南。
处理PII的责任应考虑相关法律法规。
应该采取适当的技术和组织措施来保护PII。
其他信息
一些国家已经立法控制PII的收集、处理、传输和删除。根据各自的国家立法，这种控制可以对收集、加工和传播PII的人或机构强制赋予义务，也可以限制将PII转移到其他国家的授权。
ISO/IEC 29100为在ICT系统内保护PII提供了一个高级框架。有关隐私信息管理系统的更多信息，请参见ISO/IEC 27701。关于作为PII处理器的公共云的隐私信息管理的具体信息可以在ISO/IEC 27018中找到。
ISO/IEC 29134为隐私影响评估（PIA）提供了指南，并给出了PIA报告的结构和内容示例。与ISO/IEC 27005相比，它侧重于PII处理，并与处理PII的组织相关。这有助于识别隐私风险和可能的缓解措施，以将这些风险降低到可接受的水平。
5.35 信息安全独立审查
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #保护 | #信息安全保证 | #治理与生态系统 |
控制
组织管理信息安全的方法及其实施（包括人员、流程和技术）应在计划的时间间隔或发生重大变化时进行独立审查。
目的
确保组织信息安全管理方法的持续适宜性、充分性和有效性。
指南
组织应当有进行独立评审的过程。
管理层应计划并启动定期独立审查。审查应包括评估信息安全方法的改进机会和变更需求，包括信息安全策略、专题策略和其他控制措施。
此类审查应由独立于被审查领域的个人进行（如内部审计职能部门、独立经理或专门从事此类审查的外部方组织）。执行这些审查的个人应具备适当的能力。进行审查的人员不应处于职权范围内，以确保他们具有进行评估的独立性。
独立审查的结果应报告给发起审查的管理层，如果适当，还应报告给最高管理层。这些记录应该保留。
如果独立审查发现组织管理信息安全的方法和实施不充分 [如未达到记录的目标和要求，或不符合信息安全策略和专题策略（参见5.1）中规定的信息安全方向] ，管理层应采取纠正措施。
除了定期的独立评审之外，组织还应考虑在以下情况下进行独立审查：
??a）影响组织的法律法规发生变化；
??b）发生重大事故；
??c）组织开展新业务或改变现有业务；
??d）组织开始使用新产品或服务，或改变现有产品或服务的用途；
??e）组织对信息安全控制和程序进行重大更改。
其他信息
ISO/IEC 27007和ISO/IEC TS 27008为开展独立审查提供了指南。
5.36 信息安全策略、规则和标准的遵从性
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #法律与合规性 #信息安全保证 | #治理与生态系统 |
控制
应定期审查是否符合组织的信息安全策略、专题策略、规则和标准。
目的
确保根据组织的信息安全策略、专题策略、规则和标准实施和运营信息安全。
指南
管理人员，服务、产品或信息所有人应确定如何审查信息安全策略、专题策略、规则、标准和其他适用法规中定义的信息安全要求是否得到满足。应考虑使用自动测量和报告工具进行高效的定期审查。
如果审核发现任何不合规之处，管理人员应：
??a）确定不合规的原因；
??b）评估纠正措施的需求，以实现合规性；
??c）实施适当的纠正措施；
??d）审查所采取的纠正措施，以验证其有效性，并识别任何缺陷或弱点。
应当记录由管理人员及服务、产品或信息所有人执行的评审和纠正措施的结果，并保存这些记录。当独立审查在其职责范围内进行时，管理人员应向执行独立审查的人员报告结果（参见5.35）。
应根据风险及时完成纠正措施。如果在下一次计划的评审时还没有完成，至少应该在那次评审中报告进展。
其他信息
8.15、8.16和8.17中介绍了系统使用的操作监控。
5.37 文件化的操作程序
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #恢复 | #资产管理 #物理安全 #系统和网络安全 #应用安全 #安全配置 #身份和访问管理 #威胁和漏洞管理 #连续性 #信息安全事件管理 | #治理与生态系统 #保护 #防御 |
控制
信息处理设施的操作程序应记录在案并可供需要的人使用。
目的
确保信息处理设施的正确和安全运行。
指南
应为组织与信息安全相关的运营活动编制形成文件的程序，例如：
??a）当活动需要多人以相同的方式执行时；
??b）当活动很少执行，以及当下一次执行时程序可能已经被忘记；
??c）活动是新的，如果执行不当会带来风险；
??d）在将活动移交给新员工之前。
操作程序应规定：
??a）负责的个人；
??b）系统的安全安装和配置；
??c）自动和手动处理信息；
??d）备份（参见8.13）和韧性；
??e）时间安排要求，包括与其他系统的相互依赖性；
??f）处理作业执行过程中可能出现的错误或其他异常情况的说明 [例如，限制使用实用程序（参见8.18）] ；
??g）支持和上报联系人，包括在出现意外运营或技术困难时的外部支持联系人；
??h）存储介质搬运说明（参见7.10和7.14）；
??i）发生系统故障时使用的系统重启和恢复程序；
??j）审计证据和系统日志信息（参见8.15和8.17）以及视频监控系统（参见7.4）的管理；
??k）监控程序，如容量、性能和安全性（参见8.6和8.16）；
??l）维护说明。
必要时，应审查和更新记录的操作程序。对记录的操作程序的更改应得到授权。在技术可行的情况下，应使用相同的程序、工具和实用程序对信息系统进行一致的管理。
其他信息
没有其他信息。
6 人员控制
6.1 筛选
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 | #治理与生态系统 |
控制
应在加入本组织之前对所有候选人进行背景核查，并持续考虑适用的法律、法规和道德规范，与业务要求、需要访问的信息的分类和感知的风险相称。
目的
确保所有人员都有资格并适合他们被考虑担当的角色，并在他们受雇期间保持合格和胜任。
指南
应对包括全职、兼职和临时员工在内的所有人员进行筛选。当这些个人通过服务供应商签订合同时，筛选要求应包括在组织和供应商之间的合同协议中。
应收集和处理组织内所有职位候选人的相关信息，并考虑相关司法管辖区内现有的任何适当立法。在某些司法管辖区，法律可能要求组织提前通知候选人筛选活动。
对候选人的信息的核验应顾及所有相关的隐私、PII保护和基于就业的立法，并应在允许的情况下包括以下内容：
??a）提供令人满意的佐证（如业务的和个人的证明）；
??b）申请人简历的核实（完整性和准确性）；
??c）对声称的学术和专业资格的确认；
??d）独立的身份核验（如护照或其他由有关当局签发的可接受的文件）；
??e）更详细的验证，如信用审查或犯罪记录审查（如果候选人担任关键角色）。
当某个人受聘担任特定的信息安全角色时，组织应确保候选人：
??a）具备履行安全职责的必要能力；
??b）可以被信任来担当该角色，尤其是当该角色对组织至关重要时。
如果一项工作，无论是初次任命还是晋升，涉及到有权使用信息处理设施的人员，特别是涉及到处理机密信息（如财务信息、个人信息或医疗保健信息），组织还应考虑进一步的、更详细的核验。
程序应规定核验审查的标准和限制（例如，谁有资格筛选人员，以及如何、何时和为什么进行验证审查）。
在无法及时完成核验的情况下，应实施缓解控制措施，直到审查完成，例如：
??a）延迟入职；
??b）企业资产部署延迟；
??c）入职但减少其访问权；
??d）终止雇佣。
根据人员角色的关键程度，应定期重复核验检查，以确保人员的持续胜任。
其他信息
没有其他信息。
6.2 雇佣条款和条件
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 | #治理与生态系统 |
控制
雇佣合同协议应规定员工和组织的信息安全责任。
目的
确保员工了解其所担任角色的信息安全职责。
指南
人员的合同义务应考虑到组织的信息安全策略和相关的专题策略。此外，可以澄清和说明以下几点：
??a）获得机密信息访问权限的人员在获得信息和其他相关资产的访问权限之前应签署的保密或不披露协议（参见6.6）；
??b）法律责任和权利 [例如，关于版权法或数据保护立法（参见5.32和5.34）] ；
??c）对组织信息和其他相关资产、信息处理设施和信息服务的信息分类和管理的应负责任（参见5.9至5.13）；
??d）处理从相关方收到的信息的应负责任；
??e）如果员工无视组织的安全要求，应采取的措施（参见6.4）。
在录用前流程中，应向候选人传达信息安全角色和职责。
组织应确保员工同意有关信息安全的条款和条件。这些条款和条件应适合于他们对与信息系统和服务相关的组织资产的访问的性质和范围。当法律、法规、信息安全策略或专题策略发生变化时，应审查有关信息安全的条款和条件。
在适当的情况下，雇佣条款和条件中包含的职责应在雇佣结束后的规定时间内继续有效（参见6.5）。
其他信息
行为准则可用于规定人员在保密、PII保护、道德、组织信息和其他相关资产的适当使用、以及组织期望的良好做法方面的信息安全责任。
可能会要求与供应商人员有关联的外部方代表签约个人签订合同协议。
如果组织不是法人实体并且没有员工，则可以根据此项控制的指南来考虑等同于合同协议以及条款和条件的内容。
6.3 信息安全意识、教育和培训
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 | #治理与生态系统 |
控制
组织的人员和相关利益方，应按其工作职能，接受关于组织的信息安全策略、专题策略和程序的适当的、定期更新的信息安全意识、教育和培训。
目的
确保员工和相关利益方知晓并履行其信息安全责任。
指南
常规
应根据组织的信息安全策略、专题策略和信息安全相关程序建立信息安全意识、教育和培训计划，同时考虑组织要保护的信息和为保护信息而实施的信息安全控制措施。
信息安全意识、教育和培训应定期进行。基本意识、教育和培训可以适用于新员工，也可以适用于那些调任到具有完全不同的信息安全要求的新职位或新角色的员工。
应在意识、教育或培训活动结束时评估员工的理解程度，以测试知识传授以及意识、教育和培训计划的有效性。
意识
信息安全意识计划应旨在让员工知晓他们对信息安全的责任以及履行这些责任的方式。
意识计划的策划应考虑组织中人员的作用，包括内部和外部人员（如外部顾问、供应商人员）。提高认识方案中的活动应随着时间的推移进行安排，最好是定期安排，以便重复开展活动并涵盖新员工。它还应该建立在从信息安全事件中吸取的教训的基础上。
意识程序应包括通过适当的实体或虚拟渠道开展的一系列意识提升活动，如运动、小册子、海报、通讯、网站、信息会议、简报、电子学习模块和电子邮件。
信息安全意识应涵盖一般方面，例如：
??a）管理层对整个组织信息安全的承诺；
??b）熟悉和遵守适用的信息安全规则和义务的需求，考虑信息安全策略和专题策略、标准、法律、法令、法规、合同和协议；
??c）对自己的作为和不作为承担个人责任，对获取或保护属于组织和相关方的信息承担一般责任；
??d）基本信息安全程序 [如信息安全事件报告（6.8）] 和基线控制 [如密码安全（5.17）] ；
??e）关于信息安全问题的其他信息和建议的联系点和资源，包括进一步的信息安全意识材料。
教育和培训
组织应当按其角色需要，为需具备特定技能和专业知识的技术团队确定、准备和实施适当的培训计划。技术团队应具备为设备、系统、应用程序和服务配置和维护所需安全级别的技能。如果缺少技能，组织应该采取行动并获取它们。
教育和培训方案应考虑不同的形式 [例如讲座或自学，由专家工作人员或顾问指南（在职培训），轮换工作人员参加不同的活动，招聘已经熟练的人员和聘用顾问] 。它可以使用不同的交付方式，包括基于课堂、远程学习、基于网络、自定进度等。技术人员应通过订阅时事通讯和杂志或参加旨在提高技术和专业水平的会议和活动来保持知识更新。
其他信息
在制定意识计划时，重要的是不仅要关注“是什么”和“如何”，还要尽可能关注“为什么”。员工了解信息安全的目的以及对组织自身行为的积极和消极的潜在影响是非常重要的。
信息安全意识、教育和培训可以是其他活动的一部分，或与其他活动协作进行，例如一般信息管理、信通技术、安全、隐私或安全培训。
6.4 纪律程序
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 | #人力资源安全 | #治理与生态系统 |
控制
纪律流程应正式发布和沟通，以便对违反信息安全策略的人员和其他相关利益方采取措施。
目的
确保人员和其他相关利益方了解违反信息安全策略的后果，阻止并适当处理违反策略的人员和其他相关利益方。
指南
在未事先核实发生了违反信息安全策略的情况下，不应启动纪律处分流程（参见5.28）。
正式的纪律处分程序应提供考虑以下因素的分级反馈意见：
??a）违规的性质（谁、什么、何时、如何）和严重性及其后果；
??b）犯罪是故意的（恶意的）还是无意的（意外的）；
??c）是否初犯或重犯；
??d）违规者是否受过适当的训练。
反馈意见应考虑相关法律、法规、监管合同和业务要求以及其他必要因素。纪律处分流程还应作为一种威慑手段，防止员工和其他相关利益方违反信息安全策略、专题策略和信息安全程序。故意违反信息安全策略可能需要立即采取行动。
其他信息
在可能的情况下，应根据适用的要求保护受到纪律处分的个人的身份。
当个人在信息安全方面表现出色时，他们可以获得奖励，以促进信息安全和鼓励良好行为。
6.5 雇佣关系终止或变更后的责任
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 #资产管理 | #治理与生态系统 |
控制
应定义、执行在雇佣关系终止或变更后仍然有效的信息安全责任和义务，并传达给相关人员和其他相关方。
目的
在变更或终止雇佣关系或合同的过程中保护组织的利益。
指南
管理雇佣关系终止或变更的流程应定义哪些信息安全责任和职责在终止或变更后仍然有效。这可以包括信息、知识产权和其他获得的知识的保密性，以及任何其他保密协议中包含的责任（参见6.6）。雇佣或合同终止后仍然有效的责任和义务应包含在个人的雇佣条款和条件（参见6.2）、合同或协议中。其他在个人雇佣关系结束后持续一段时间的合同或协议也可能包含信息安全责任。
责任或雇佣的变化应作为当前责任或雇佣的终止与新责任或雇佣的开始相结合进行管理。
任何离职或变更工作角色的个人所担任的信息安全角色和职责都应确定并移交给另一个人。
应当建立向人员、其他相关方和相关联系人（如顾客和供应商）传达变更和运行程序的过程。
当组织中的人员、合同或工作终止时，或者当组织内部的工作发生变化时，终止或变更雇佣关系的流程也应适用于外部人员（即供应商）。
其他信息
在许多组织中，人力资源部门通常负责整个离职流程，并与离职人员的主管经理一起管理相关程序的信息安全方面。对于通过外部方提供的人员（如通过供应商），终止过程由外部方根据组织与外部方之间的合同进行。
6.6 保密或不披露协议
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 | #保护 | #人力资源安全 #信息保护 #供应商关系 | #治理与生态系统 |
控制
反映组织信息保护需求的保密或不披露协议应当由员工和其他相关方识别、形成文件、定期评审和签署。
目的
保持人员或外部各方可访问信息的机密性。
指南
保密或不披露协议应使用法律强制条款来满足保护机密信息的要求。保密协议适用于相关方和组织人员。根据组织的信息安全要求，在确定协议中的条款时，应考虑将要处理的信息类型、其分类级别、其用途以及允许另一方访问的信息。为了确定保密或不披露协议的要求，应考虑以下因素：
??a）受保护信息的定义（如机密信息）；
??b）协议的预期期限，包括可能需要无限期保密或在信息公开之前保密的情况；
??c）协议终止时需要采取的措施；
??d）签署人避免未经授权的信息披露的责任和行为；
??e）信息、商业秘密和知识产权的所有权，以及这与保护机密信息的关系；
??f）机密信息的许可使用和签字人使用该信息的权利；
??g）在高度敏感的情况下，有权审计和监督涉及机密信息的活动；
??h）通知和报告未经授权的披露或机密信息泄漏的流程；
??i）协议终止时返还或销毁信息的条款；
??j）在不符合协议的情况下预期采取的行动。
组织应考虑遵守适用于其管辖范围的保密和不披露协议（参见5.31、5.32、5.33、5.34）。
应定期审查保密和不披露协议的要求，并在发生影响这些要求的变化时进行审查。
其他信息
保密和不披露协议保护组织的信息，并告知签署者，他们有责任以负责任和授权的方式保护、使用和披露信息。
6.7 远程工作
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 #信息保护 #物理安全 #系统和网络安全 | #保护 |
控制
当员工远程工作时，应实施安全措施来保护在组织场所之外访问、处理或存储的信息。
目的
确保员工远程工作时的信息安全。
指南
每当本组织人员在本组织主场地之外的地点工作，通过ICT设备以硬拷贝或电子方式获取信息时，就会发生远程工作。远程工作环境包括那些被称为“远程工作”、“远程办公”、“灵活工作场所”、“虚拟工作环境”和“远程维护”的环境。
注意，由于不同司法管辖区的当地立法和法规，可能无法适用本指南中的所有建议。
允许远程工作活动的组织应发布关于远程工作的专题策略，定义相关条件和限制。如果适用，应考虑以下事项：
??a）远程工作现场的现有或拟议的物理安全，考虑该位置和当地环境的物理安全，包括人员所在的不同管辖区；
??b）远程物理环境的规则和安全机制，如可上锁的文件柜、地点之间的安全传输、远程访问规则、桌面清洁、信息和其他相关资产的打印和处置，以及信息安全事件报告（参见6.8）；
??c）预期的远程物理工作环境；
??d）通信安全要求，考虑到远程访问本组织系统的需要、通过通信链路访问和传递的信息的敏感性以及系统和应用程序的敏感性；
??e）使用远程访问，如支持在私有设备上处理和存储信息的虚拟桌面访问；
??f）远程工作场所的其他人（如家人和朋友）未经授权访问信息或资源的威胁；
??g）在公共场所的其他人未经授权获取信息或资源的威胁；
??h）家庭网络和公共网络的使用，以及对无线网络服务配置的要求或限制；
??i）使用安全措施，如防火墙和防恶意软件；
??j）远程部署和初始化系统的安全机制；
??k）安全的身份验证和访问权限激活机制，考虑到允许远程访问组织网络的单因素身份验证机制的漏洞。
要考虑的准则和措施应包括：
??a）在不允许使用不受组织控制的私有设备的情况下，为远程工作活动提供合适的设备和存储家具；
??b）许可的工作的定义、可保存的信息的分类以及远程员工有权访问的内部系统和服务；
??c）为远程工作人员和提供支持的人员提供培训。这应包括如何在远程工作时以安全的方式开展业务；
??d）提供合适的通信设备，包括保护远程访问的方法，如对设备屏幕锁定和静止计时器的要求；启用设备位置跟踪；安装远程擦除功能；
??e）人身安全；
??f）关于家庭成员和访客获取设备和信息的规则和指南；
??g）提供硬件和软件支持和维护；
??h）提供保险；
??i）备份和业务连续性程序；
??j）审计和安全监控；
??k）当远程工作活动终止时，撤销权限和访问权并归还设备。
其他信息
没有其他信息。
6.8 报告信息安全事件
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #检测性 | #保密性 #完整性 #可用性 | #检测 | #信息安全事件管理 | #防御 |
控制
组织应提供一种机制，让员工通过适当的渠道及时报告观察到的或怀疑的信息安全事件。
目的
支持及时、一致和有效地报告可被员工识别的信息安全事件。
指南
所有人员和用户都应意识到他们有责任尽快报告信息安全事件，以防止或最大限度地减少信息安全事件的影响。
他们还应了解报告信息安全事件的程序以及应向其报告事件的联系人。报告机制应尽可能简单、容易获得和可用。信息安全事件包括事故、违规和漏洞。
信息安全事件报告需要考虑的情况包括：
??a）无效的信息安全控制；
??b）违背信息机密性、完整性或可用性预期；
??c）人为错误；
??d）不符合信息安全策略、专题策略或适用标准；
??e）违被物理安全措施；
??f）未通过变更管理流程的系统变更；
??g）软件或硬件的故障或其他异常系统行为；
??h）访问违规；
??i）漏洞；
??j）可疑的恶意软件感染。
应建议员工和用户不要试图证明可疑的信息安全漏洞。测试漏洞可以被解释为对系统的潜在滥用，也可能对信息系统或服务造成损害，并且可能破坏或模糊数字证据。最终，这可能导致执行测试的个人承担法律责任。
其他信息
更多信息请参见ISO/IEC 27035系列。
7 物理控制
7.1 物理安全周界
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 | #保护 |
控制
应该定义安全边界，并用于保护包含信息和其他相关资产的区域。
目的
防止对组织信息和其他相关资产的未经授权的物理访问、损坏和干扰。
指南
在适用于物理安全边界的情况下，应考虑并实施以下指南：
??a）根据与周界内资产有关的信息安全要求，确定安全周界以及每个周界的位置和强度；
??b）拥有包含信息处理设施的建筑物或场所的物理上合理的周界（即周界或区域中不应有容易发生闯入的空隙）。现场的外部屋顶、墙壁、天花板和地板应为实心结构，所有外门应采用控制机制（例如，栅栏、警报器、锁）进行适当保护，防止未经授权的进入。无人看管时，门窗应上锁，应考虑对窗户进行额外保护，尤其是在建筑第一层；还应顾及通风点；
??c）报警、监控和测试安全周界上的所有防火门以及墙壁，以根据适当的标准建立所需的抵抗力水平。它们应该以安全的方式运行。
其他信息
可在组织的场所和信息处理设施周围建立一个或多个物理屏障以实现物理保护。
安全区域可以是一个可上锁的办公室或几个被连续的内部物理安全屏障包围的房间。在安全边界内具有不同安全要求的区域之间，可能需要额外的屏障和边界来控制物理访问。组织应考虑在威胁增加的情况下加强物理安全措施。
7.2 物理入口
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 #身份和访问管理 | #保护 |
控制
安全区域应通过适当的入口控制和访问点进行保护。
目的
确保只出现经过授权的对组织信息和其他相关资产的物理访问。
指南
常规
应控制访问点，如交付和装载区以及未经授权的人员可能进入的其他地方，如果可能，还应将其与信息处理设施隔离，以避免未经授权的进入。
应考虑以下指南：
??a）仅限授权人员进入现场和建筑物。物理区域访问权限的管理流程应包括授权的提供、定期审查、更新和撤销（参见5.18）；
??b）安全维护和监控所有访问的物理日志或电子审计跟踪，并保护所有日志（参见5.33）和敏感认证信息；
??c）建立和实施流程和技术机制，以管理对信息处理或存储区域的访问。认证机制包括使用门禁卡、生物识别技术或双因素认证，如门禁卡和密码。进入敏感区域应考虑双重安全门；
??d）设立一个由人员监控的接待区，或通过其他方式控制现场或建筑物的实际出入；
??e）检查、查验出入人员和有关当事人的个人物品；
??????注意：关于检查人员物品的可能性，应顾及当地法律法规。
??f）要求所有人员和相关方佩戴某种形式的可见标识，并在遇到无人陪同的访客和未佩戴可见标识的人员时立即通知安保人员。应考虑使用易于识别的徽章，以便更好地识别永久员工、供应商和访客；
??g）仅在需要时，授予供应商人员对安全区域或信息处理设施的有限访问权。这种访问应该得到授权和监控；
??h）在建筑物是被多个组织持有的资产的情况下，特别注意物理访问安全；
??i）设计物理安全措施，以便在发生实体事故的可能性增加时加强这些措施；
??j）保护其他入口，如紧急出口，防止未经授权的进入；
??k）建立钥匙管理流程，以确保管理物理钥匙或认证信息（如办公室、房间和设施（如钥匙柜）的锁代码、密码锁），并确保日志簿或年度钥匙审计，以及对物理钥匙或认证信息的访问受到控制（有关认证信息的进一步指导，请参见5.17）。
访客
应考虑以下指南：
??a）通过适当的方式验证访问者的身份；
??b）记录访客进出的日期和时间；
??c）只准许访客出于特定的授权目的进入，并说明该地区的安全要求和应急程序；
??d）监督所有访客，除非有明确的例外情况。
交货和装货区以及来料
应考虑以下指南：
??a）限制经确认和授权的人员从建筑物外部进入交付和装载区域；
??b）设计交付和装载区域，以便交货人员无须被授权进入大楼其他部分即可完成货物装卸；
??c）当限制区域的门打开时，保护交付和装载区域的外门；
??d）在爆炸物、化学品或其他危险材料运出交货和装载区之前，对其进行检查和检验；
??e）进入场所时，根据资产管理程序（参见5.9和7.10）登记进货；
??f）在可能的情况下，对进与出的货物进行物理隔离；
??g）在运送过程中检查是否有破坏的迹象。如果发现破坏，应立即向安全人员报告。
其他信息
没有其他信息。
7.3 保护办公室、房间和设施
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 #资产管理 | #保护 |
控制
应设计和实施办公室、房间和设施的物理安全。
目的
防止未经授权的物理访问、损坏和干扰处于办公室、房间和设施中的组织信息和其他相关资产。
指南
应考虑以下指南来保护办公室、房间和设施的安全：
??a）关键设施的场所应避免公众进入；
??b）在适用的情况下，确保建筑物不引人注目，并尽可能少地说明它们的用途，建筑物内外没有明显的标志显示出该处所存在信息处理活动；
??c）配置设施以防止机密信息或活动被外界看到或听到。电磁屏蔽也应酌情考虑；
??d）不向任何未授权人员提供标识机密信息处理设施位置的目录、内部电话簿和在线地图。
其他信息
没有其他信息。
7.4 物理安全监控
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 | #保密性 #完整性 #可用性 | #保护 #检测 | #物理安全 | #保护 #防御 |
控制
应对场所进行持续监控，防止未经授权的物理访问。
目的
检测和阻止未经授权的物理访问。
指南
应通过监控系统对实际场所进行监控，监控系统可包括警卫，入侵警报，闭路电视等视频监控系统，以及自管理或由监控服务提供商管理的物理安全信息管理软件。
应通过以下方式持续监控关键系统所在建筑物的出入情况，以检测未经授权的出入或可疑行为：
??a）安装闭路电视等视频监控系统，以查看和记录进出组织房地内外敏感区域的情况；
??b）根据相关适用标准安装并定期测试接触、声音或运动探测器，以触发入侵警报，例如：
??????1）在任何可能接触或断开的地方（如窗户、门和物体下面）安装接触探测器，当接触或断开时触发警报，用作紧急警报；
??????2）基于红外技术的运动探测器，当物体通过其视野时触发警报；
??????3）安装对玻璃破碎声音敏感的传感器，可用于触发警报，提醒安保人员；
??c）使用这些警报覆盖所有外门和可进入的窗户。无人驻留的区域应随时报警；还应为其他区域（如计算机或通信室）提供遮盖物。
监控系统的设计应该保密，因为泄露会导致未被发现的非法闯入。
应保护监控系统免受未经授权的访问，以防止未经授权的人员访问监控信息（如视频馈送）或远程禁用系统。
报警系统控制面板应放置在有警报装置的区域，并且，考虑到人身安全，应放置在可为设置报警的人提供便捷撤离路线的位置。控制面板和探测器应具有防改装破坏机制。应定期测试系统，以确保其正常工作，尤其是当其组件由电池供电时。
使用任何监控和记录机制应考虑当地法律法规，包括数据保护和PII保护立法，尤其是关于人员监控和记录视频保留期的法律法规。
其他信息
没有其他信息。
7.5 抵御物理和环境威胁
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 | #保护 |
控制
应设计和实施针对物理和环境威胁的保护措施，如自然灾害和对基础设施的其他有意或无意的物理威胁。
目的
预防或减少源于物理和环境威胁的事件的影响。
指南
应在物理站点开始关键操作之前执行并定期执行风险评估，以确定物理和环境威胁的潜在后果。应实施必要的安全措施，并监控威胁的变化。应就如何管理物理和环境威胁（如火灾、洪水、地震、爆炸、内乱、有毒废物、环境排放和其他形式的自然灾害或人为灾害）引起的风险征求专家意见。
物理场所的位置和建设应考虑到：
??a）当地地形，如适当的海拔、水体和构造断层线；
??b）城市威胁，如吸引政治动乱、犯罪活动或恐怖袭击的高知名度地点。
根据风险评估结果，应确定相关的物理和环境威胁，并在以下情况下考虑适当的控制措施，例如：
??a）火灾：安装和配置能够在早期发现火灾的系统，以发送警报或触发灭火系统，从而防止火灾对存储介质和相关信息处理系统造成损害。应使用与周围环境相关的最合适的物质进行灭火（例如密闭空间中的气体）；
??b）洪水：在包含存储介质或信息处理系统的区域的地板下安装能够在早期检测洪水的系统。万一发生洪水，应准备好水泵或同等工具；
??c）电涌：采用能够保护服务器和客户机信息系统免受电涌或类似事件影响的系统，以尽量减少此类事件的影响；
??d）爆炸物和武器：随机检查进入敏感信息处理设施的人员、车辆或货物上是否有爆炸物或武器。
其他信息
保险箱或其他形式的安全存储设施可以保护存储在其中的信息免受诸如火灾、地震、洪水或爆炸等灾难的影响。
组织在设计控制措施以保护其环境和减少城市威胁时，可以考虑通过环境设计预防犯罪的概念。例如可以布置雕像或水景来替代护柱，即是装饰景观又可作为物理屏障。
7.6 在安全区域工作
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 | #保护 |
控制
应设计并实施在安全区域工作的安全措施。
目的
保护安全区域中的信息和其他相关资产，使其免受在这些区域工作的人员的损坏和未经授权的干扰。
指南
在安全区域工作的安全措施应适用于所有人员，并涵盖在安全区域发生的所有活动。
应考虑以下准则：
??a）在按需所知的基础上，使人员只知道安全区域的存在或其内的活动；
??b）出于人身安全原因和减少恶意活动的机会，避免在安全区域进行无人监督的工作；
??c）物理锁定并定期检查空闲的安全区域；
??d）除非获得授权，否则不允许使用照相、视频、音频或其他记录设备，如用户终端设备中的摄像头；
??e）在安全区域适当控制用户终端设备的携带和使用；
??f）以容易看到或容易获取的方式张贴应急程序。
其他信息
没有其他信息。
7.7 桌面清理和屏幕清理
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 | #保护 | #物理安全 | #保护 |
控制
应定义并适当强制针对纸张和可移动存储介质的桌面清理规则，以及信息处理设施的屏幕清理规则。
目的
针对桌面、屏幕和其他类似可访问位置上的信息，降低未经授权的访问、丢失和损坏的风险，包括在正常工作时间期间或之外。
指南
组织应当建立并向所有相关利益方传达桌面清理和屏幕清理的专题策略。
应考虑以下指南：
??a）在不需要时，特别是当办公室被腾空时，锁定敏感或关键的业务信息（例如，在纸上或电子存储介质上）（最好放在保险箱、柜子或其他形式的安全家具中）。
??b）当不使用或无人看管时，通过钥匙锁或其他安全手段保护用户终端设备；
??c）当无人照管时，让用户终端设备注销或用由用户认证机制控制的屏幕和键盘锁定机制来保护。所有计算机和系统都应配置超时或自动注销功能；
??d）让发起者立即取走打印机或多功能设备的输出。使用具有身份鉴别功能的打印机，使发起者是唯一能获得打印输出的人，并且必须站在打印机旁边时才能获得；
??e）安全地存放包含敏感信息的文档和可移动存储介质，当不再需要时，使用安全处置机制将其作废；
??f）建立并传达屏幕弹出窗口配置的规则和指南（例如，如果可能，在演示、屏幕共享或公共区域关闭新的电子邮件和消息弹出窗口）；
??g）当不再需要时，清除白板和其他类型显示器上的敏感或关键信息。
组织应制定撤离设施的程序，包括在离开前进行最后一次清扫，以确保组织的资产不会被遗忘（例如，文件落在抽屉或家具后面）。
其他信息
没有其他信息。
7.8 设备安置和保护
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 #资产管理 | #保护 |
控制
设备应安全放置并受到保护。
目的
降低来自物理和环境威胁以及未经授权的访问和损坏的风险。
指南
应考虑以下指南来保护设备：
??a）设备选址应尽量减少对工作区域的不必要访问，并避免未经授权的访问；
??b）谨慎放置处理敏感数据的信息处理设施，以降低信息在使用过程中被未授权人员查看的风险；
??c）采取控制措施，最大限度地降低潜在物理和环境威胁的风险 [例如，盗窃、火灾、爆炸、烟雾、水（或供水故障）、灰尘、振动、化学影响、供电干扰、通信干扰、电磁辐射和故意破坏] ；
??d）为信息处理设施附近的饮食和吸烟制定指南；
??e）监控环境条件，例如温度和湿度，以发现可能对信息处理设施的运行产生不利影响的条件；
??f）对所有建筑物实施防雷，并对所有电力接入和通信线路安装防雷过滤器；
??g）考虑对工业环境中的设备使用特殊的保护方法，如键盘膜；
??h）保护处理机密信息的设备，最大限度降低因电磁辐射导致的信息泄露风险；
??i）物理隔离组织管理的和不归组织管理的信息处理设施。
其他信息
没有其他信息。
7.9 场外资产的安全
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 #资产管理 | #保护 |
控制
应保护场外资产。
目的
防止场外设备的丢失、损坏、被盗或侵害，防止组织运营的中断。
指南
在组织场所之外使用的存储或处理信息的任何设备（例如移动设备），包括组织拥有的设备和代表组织使用的私有设备 [自带设备（BYOD）] 都需要保护。这些设备的使用应得到管理层的授权。
为保护组织场所之外的储存或加工信息的设备，应考虑以下指南：
??a）不要将设备和存储介质放在无人看管的公共场所和不安全的地方；
??b）始终遵守制造商关于保护设备的说明（例如，防止暴露在强电磁场、水、热、湿度、灰尘中）；
??c）当异地设备在不同的个人或相关方之间转移时，维护一个日志，该日志定义了设备的监管链，至少包括设备负责人的姓名和组织。不需要随资产一起转移的信息应在转移前安全删除；
??d）在必要和可行的情况下，要求授权后才能从组织场所移走设备和介质，并保存此类调动的记录作为审计线索（参见5.14）；
??e）防止在公共交通工具上查看设备（如手机或笔记本电脑）上的信息，以及其他与肩窥相关的风险；
??f）实现位置跟踪和远程擦除设备的能力。
在组织场所之外安装永久设备 [如天线和自动柜员机（ATM）] 可能面临更高的损坏、被盗或被窃听风险。这些风险可能因地点不同而有很大差异，在确定最合适的措施时应予以考虑。
将该设备放置在组织场所之外时，应考虑以下指南：
??a）物理安全监控（参见7.4）；
??b）防止物理和环境威胁（参见7.5）；
??c）物理访问和防改装控制；
??d）逻辑访问控制。
其他信息
有关保护信息存储和处理设备以及用户终端设备的其他方面的更多信息，请参见8.1和6.7。
7.10 存储介质
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 #资产管理 | #保护 |
控制
应根据组织的分类方案和处理要求，在采购、使用、运输和处置的整个生命周期中对存储介质进行管理。
目的
确保仅授权披露、修改、删除或销毁存储介质上的信息。
指南
可移动存储介质
应考虑以下可移动存储介质管理指南：
??a）建立关于可移动存储介质管理的专题策略，并将该专题策略传达给使用或处理可移动存储介质的任何人；
??b）在必要和可行的情况下，要求授权后才能从组织中移除存储介质，并保留此类移除的记录作为审计线索；
??c）按照制造商的规范，根据信息分类将所有存储介质存储在安全可靠的环境中，并保护它们免受环境威胁（如热、湿气、湿度、电子场或老化）；
??d）如果信息的机密性或完整性是重要的考虑因素，则使用加密技术来保护可移动存储介质上的信息；
??e）为了降低存储介质降级的风险，在无法读取之前将仍然需要存储的信息传输到新的存储介质中；
??f）将有价值信息的多个副本分别存储在单独的存储介质上，以进一步降低信息同时损坏或丢失的风险；
??g）考虑注册可移动存储介质，以减少信息丢失的机会；
??h）启用可移动存储介质端口 [例如，安全数字（SD）卡插槽和通用串行总线（USB）端口] 必须是出于组织需要使用的理由；
??i）在需要使用可移动存储介质时，监控信息向该存储介质的传输；
??j）在物理传输过程中，信息很容易受到未经授权的访问、误用或破坏，例如通过邮政服务或快递发送存储介质。
在此控制中，介质包括纸质文档。转移物理存储介质时，应用5.14中的安全措施。
安全再利用或作废
应建立安全再利用或作废存储介质的程序，最大限度地降低机密信息泄露给未授权人员的风险。包含机密信息的存储介质的安全再利用或处置程序应与该信息的敏感性相称。应考虑以下事项：
??a）如果包含机密信息的存储介质需要在组织内再利用，则在再利用之前安全地删除数据或格式化存储介质（参见8.10）；
??b）不再需要时，安全作废包含机密信息的存储介质（例如，通过销毁、粉碎或安全删除内容）；
??c）制定程序以识别需要安全作废的物品；
??d）许多组织提供存储介质的收集和作废服务。应注意选择具有足够控制和经验的合适外部供应商；
??e）记录敏感物品的处置情况，以保留审计线索；
??f）在为准备作废而积聚存储介质时，要考虑聚合效应，大量非敏感信息聚合后会变得敏感。
应对包含敏感数据的受损设备进行风险评估，以确定这些设备是否应被物理销毁，而不是送去维修或丢弃（参见7.14）。
其他信息
当存储介质中的机密信息未加密时，应考虑对存储介质进行额外的物理保护。
7.11 支持性设施
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 | #完整性 #可用性 | #保护 #检测 | #物理安全 | #保护 |
控制
应对信息处理设施进行保护，使其免受电力故障和其他由支持设施故障造成的中断的影响。
目的
防止信息和其他相关资产的丢失、损坏或受侵害，或防止因支持设施的故障和中断而使组织的运营中断。
指南
组织依靠支持性设施（例如电力、电信、供水、煤气、污水、通风和空调）来支持其信息处理设施。因此，本组织应该：
??a）确保支持支持性设施的设备按照相关制造商的规范进行配置、操作和维护；
??b）确保定期评估支持性设施的能力，以满足业务增长以及与其他支持性设施互动的要求；
??c）确保定期检查和测试支持支持性设施的设备，以确保其正常运行；
??d）如有必要，发出警报以检测支持性设施故障；
??e）如有必要，确保支持性设施具有多路不同物理路由的馈电；
??f）如果联网，确保支持支持性设施的设备与信息处理设施位于不同的网络上；
??g）确保支持支持性设施的设备仅在需要时以安全的方式连接到互联网。
应提供应急照明和通信。电、水、气或其他支持性设施的紧急开关和阀门应位于紧急出口或设备室附近。应详细记录紧急联系方式，确保在断供时对相关人员可用。
其他信息
冗余的网络连接可以通过来自多个支持性设施提供商的多条路由获得。
7.12 布线安全
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #可用性 | #保护 | #物理安全 | #保护 |
控制
承载电力、数据或支持信息服务的电缆应受到保护，以免被截取、干扰或损坏。
目的
防止信息和其他相关资产的丢失、损坏、被盗或受侵害，防止与电力和通信布线相关的组织运营中断。
指南
应考虑以下布线安全指南：
??a）进入信息处理设施的电力和电信线路尽可能位于地下，或受到适当的替代保护，如地面电缆保护器和电线杆；如果电缆在地下，保护它们免受意外切割（如用铠装导管或显要标志）；
??b）将电力电缆与通信电缆分开，以防止干扰；
??c）对于敏感或关键系统，要考虑的进一步控制措施包括：
??????1）在检查点和端接点安装铠装导管，使用上锁的房间或箱子以及警报器；
??????2）使用电磁屏蔽保护电缆；
??????3）定期进行技术扫描和物理检查，及时发现连接到线缆上的未授权设备；
??????4）控制对接线板和布线间的访问（例如使用机械钥匙或插销）；
??????5）光纤电缆的使用；
??d）在电缆的每一端贴上标签，注明充分的来源和目的信息，以便对电缆进行物理识别和检查。
应就如何管理布线事故或故障引起的风险寻求专家建议。
其他信息
有时，电力和电信布线是进驻同一场所的多个组织的共享资源。
7.13 设备维护
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #物理安全 #资产管理 | #保护 #韧性 |
控制
应正确维护设备，以确保信息的可用性、完整性和保密性。
目的
防止信息和其他相关资产的丢失、损坏、被盗或受侵害，以及因缺乏维护而导致的组织运营中断。
指南
应考虑以下设备维护指南：
??a）根据供应商推荐的服务频率和规范维护设备；
??b）组织实施和监测维护方案；
??c）仅由获授权的维护人员对设备进行维修和维护；
??d）保存所有可疑或实际故障的记录，以及所有预防性和纠正性维护的记录；
??e）当设备计划进行维护时，实施适当的控制，同时考虑维护是由现场人员还是组织外部人员执行；要求维护人员遵守适当的保密协议；
??f）维修人员进行现场维修应受监督；
??g）授权和控制远程维护的访问；
??h）如果包含信息的设备被带离现场进行维护，则对现场外的资产采取安全措施（参见7.9）；
??i）遵守保险公司规定的所有维护要求；
??j）在维修后将设备投入运行之前，检查设备以确保设备未被改动且运行正常；
??k）如果确定要作废设备，则采取安全作废或再利用设备的措施（参见7.14）。
其他信息
设备包括信息处理设施的技术组件、不间断电源和电池、发电机、交流发电机和变流器、物理入侵探测系统和警报、烟雾探测器、灭火器、空调和电梯。
7.14 设备的安全作废或再利用
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 | #保护 | #物理安全 #资产管理 | #保护 |
控制
应验证包含存储介质的设备，以确保任何敏感数据和许可软件在作废或再利用之前已被删除或安全覆盖。
目的
防止信息从待作废或再利用的设备中泄漏。
指南
应对设备进行验证，以确认在作废或再利用之前是否包含存储介质。
应物理销毁包含机密或版权信息的存储介质，或者使用能使原始信息不可检索的技术，而不是使用标准的删除功能来销毁、删除或覆盖信息。有关存储介质安全作废的详细指南，请参见7.10；有关信息删除的指南，请参见8.10。
在作废（包括转售或捐赠给慈善机构）之前，应移除标识组织或表明分类、所有者、系统或网络的标签和标记。
组织应考虑在租赁结束时或搬出办公场所时撤除安全控制，如出入控制或监控设备。这取决于以下因素：
??a）将设施恢复原状的租赁协议；
??b）最大限度地降低将含有敏感信息的系统留给下一个租户的风险（例如，用户访问列表、视频或图像文件）；
??c）在下一个场所重新使用控制的可能性。
其他信息
包含存储介质的损坏设备可能需要进行风险评估，以确定是否应对这些物品进行物理销毁，而不是送去维修或丢弃。不谨慎的作废或再利用设备可能会危及信息安全。
除了安全删除磁盘之外，全磁盘加密也可以降低设备处置或重新部署时泄露机密信息的风险，前提是：
??a）加密过程足够强大，并且覆盖整个磁盘（包括残留空间、交换文件）；
??b）密钥足够长，可以抵御暴力攻击；
??c）密钥本身是保密的（例如，从不存储在同一个磁盘上）。
有关加密的更多建议，请参见8.24。
根据存储介质技术和存储介质上的信息的分类级别，用于安全地覆写存储介质的技术会有所不同。应审查覆写工具以确保适用。
关于存储介质净化方法的详细信息，请参见ISO/IEC 27040。
8 技术控制
8.1 用户终端设备
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全领域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 #信息保护 | #保护 |
控制
存储在用户终端设备上、由用户终端设备处理或可通过用户终端设备访问的信息应受到保护。
目的
保护信息免受由于使用用户终端设备而带来的风险。
指南
常规
组织应针对用户终端设备的安全配置和处理制定专题策略。专题策略应传达给所有相关人员，并考虑以下内容：
??a）用户终端设备可以处理、加工、存储或支持的信息类型和分类级别；
??b）用户终端设备的注册；
??c）物理保护的要求；
??d）软件安装的限制（例如由系统管理员远程控制）；
??e）对用户终端设备软件（包括软件版本）和应用更新（例如主动自动更新）的要求；
??f）连接到信息服务、公共网络或任何其他外部网络的规则（例如，要求使用个人防火墙）；
??g）访问控制；
??h）存储设备加密；
??i）防范恶意软件；
??j）远程禁用、删除或锁定；
??k）备份；
??l）网络服务和网络应用的使用；
??m）最终用户行为分析（参见8.16）；
??n）使用可移动设备，包括可移动存储设备，以及禁用物理端口（例如USB端口）的可能性；
??o）使用分区功能（如果用户终端设备支持），安全地将组织的信息和其他相关资产（例如软件）与设备上的其他信息和其他相关资产分开。
应考虑某些信息是否非常敏感，只能通过用户终端设备访问，而不能存储在此类设备上。在这种情况下，设备可能需要额外的技术保护。例如，确保禁用下载文件进行脱机工作，并禁用SD卡等本地存储。
应尽可能通过配置管理（参见8.9）或自动化工具来实施关于此项控制的建议。
用户责任
所有用户都应了解保护用户终端设备的安全要求和程序，以及他们实施这些安全措施的责任。应建议用户：
??a）注销活动会话并在不再需要时终止服务；
??b）不使用时，通过物理控制（如钥匙锁或特殊锁）和逻辑控制（如密码访问）保护用户终端设备免受未经授权的使用；不要让载有重要、敏感或关键业务信息的设备无人看管；
??c）在公共场所、开放式办公室、会议场所和其他不受保护的区域使用设备时要特别谨慎（例如，其他人是否可以从身后阅读，避免阅读机密信息，使用隐私屏幕过滤器）；
??d）从物理上保护用户终端设备免遭盗窃（例如，在汽车和其他交通工具、酒店房间、会议中心和会议场所）。
对于用户终端设备被盗或丢失的情况，应建立考虑法律、法规、监管、合同（包括保险）和组织的其他安全要求的特定程序。
个人设备的使用
当组织允许使用个人设备（有时称为BYOD）时，除了此项控制中给出的指导外，还应考虑以下内容：
??a）将设备的个人和商业用途分离，包括使用软件支持这种分离并保护私人设备上的商业数据；
??b）仅在用户确认其职责（物理保护、软件更新等）后，才提供对业务信息的访问。放弃业务数据的所有权，允许组织在设备被盗或丢失或不再有权使用该服务时远程擦除数据。在这种情况下，应考虑PII保护法规；
??c）专题策略和程序，防止与在私有设备上开发的知识产权相关的争议；
??d）访问私人拥有的设备（以验证机器的安全性或在调查过程中），这是可能被法律阻止的；
??e）软件许可协议，即组织可以负责在个人或外部用户私有的用户终端设备上许可客户端软件
无线连接
组织应当建立以下程序：
??a）设备上无线连接的配置（例如，禁用易受攻击的协议）；
??b）根据相关专题策略，使用具有适当带宽的无线或有线连接（例如，因为需要备份或软件更新）。
其他信息
保护用户终端设备上的信息的控制措施，取决于用户终端设备是仅在组织的安全场所和网络连接内部使用，还是在组织外部面临更多的物理和网络相关威胁。
用户终端设备的无线连接类似于其他类型的网络连接，但在识别控制时应考虑到它们之间的重要差异。特别是，存储在用户终端设备上的信息的备份有时会失败，因为网络带宽有限，或者因为在安排备份时用户终端设备没有连接。
对于某些USB端口，如USB-C，禁用USB端口是不可能的，因为它用于其他目的（如供电和显示输出）。
8.2 特殊访问权
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
控制
应该限制和管理特殊访问权的分配和使用。
目的
确保只有授权用户才能获得软件组件和服务的特殊访问权。
指南
特殊访问权的分配应根据访问控制相关的专题策略（参见5.15）通过授权流程进行控制。应考虑以下几点：
??a）确定需要对每个系统或流程（如操作系统、数据库管理系统和应用程序）拥有特殊访问权的用户；
??b）根据关于访问控制的专题策略（参见5.15），根据需要和具体事件向用户分配特殊访问权（即仅向具有必要能力的个人分配，以执行需要特权访问的活动，并基于其职能角色的最低要求）；
??c）维护授权过程（即确定谁可以批准特殊访问权，或者在授权过程完成之前不授予特殊访问权）和所有分配的特权的记录；
??d）定义和实施特殊访问权到期的要求；
??e）采取措施确保用户知道他们的特殊访问权以及他们何时处于特权访问模式。可能的措施包括使用特定的用户身份、用户界面设置甚至特定的设备；
??f）特殊访问权的身份验证要求可高于一般访问权限的要求。在使用特殊访问权进行工作之前，可能需要进行重新身份验证或进一步身份验证；
??g）定期地，以及在任何组织变更之后，审查使用特殊访问权的用户，以验证他们的职责、角色、责任和能力是否仍然使他们有资格使用特殊访问权（参见5.18）；
??h）根据系统的配置功能，建立特定规则以避免使用通用的管理用户ID（如“root”）。管理和保护这些身份的认证信息（参见5.17）；
??i）仅在实施批准的变更或活动（例如，维护活动或某些关键变更）所需的时间窗口内授予临时特殊访问权，而不是永久授予特殊访问权。这通常被称为“击碎玻璃”程序，并且通常通过特权访问管理技术来自动化；
??j）出于审计目的，记录对系统的所有特权访问；
??k）不向多个人共享或链接具有特殊访问权的身份，向每个人分配单独的身份，从而允许分配特定的特殊访问权。可以对身份进行分组（例如，通过定义管理员组），以便简化特殊访问权的管理；
??l）具有特殊访问权的身份仅用于执行管理任务，而不是日常的一般任务 [例如，检查电子邮件、访问网络（用户应该有单独的正常网络身份用于这些活动）] 。
其他信息
特殊访问权是提供给身份、角色或流程的访问权限，允许执行典型用户或流程无法执行的活动。系统管理员角色通常需要特殊访问权。
不当使用系统管理员权限（信息系统的任何功能或设施，使用户能够超越系统或应用程序控制）是系统故障或违背的一个主要促成因素。
有关访问管理和信息访问安全管理以及信息和通信技术资源的更多信息，请参见ISO/IEC 29146。
8.3 信息访问约束
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
控制
对信息和其他相关资产的访问应根据既定的关于访问控制的专题策略进行约束。
目的
确保仅授权访问，防止未经授权访问信息和其他相关资产。
指南
应根据既定的专题策略约束对信息和其他相关资产的访问。为了支持访问约束要求，应考虑以下事项：
??a）不允许未知用户身份或匿名访问敏感信息。公共或匿名访问只应授予不包含任何敏感信息的存储位置；
??b）提供配置机制以控制对系统、应用程序和服务中信息的访问；
??c）控制特定用户可以访问哪些数据；
??d）控制哪些身份或身份组具有哪些访问权限，例如读、写、删除和执行；
??e）提供物理或逻辑访问控制，以隔离敏感的应用程序、应用程序数据或系统。
此外，当组织执行以下操作时，应考虑使用动态访问管理技术和流程来保护对组织具有高价值的敏感信息：
??a）需要精确控制谁可以在什么时间以什么方式访问此类信息；
??b）希望与组织外的人员共享此类信息，并保持对可访问信息的人员的控制；
??c）想要实时动态管理此类信息的使用和分发；
??d）希望保护此类信息免遭未经授权的更改、复制和分发（包括打印）；
??e）想要监控信息的使用；
??f）希望记录此类信息发生的任何变化，以备将来需要调查。
动态访问管理技术应在信息的整个生命周期（即创建、处理、存储、传输和处置）中保护信息，包括：
??a）基于特定用例建立动态访问管理规则，考虑：
??????1）基于身份、设备、位置或应用授予访问权限；
??????2）利用分类方案来确定哪些信息需要使用动态访问管理技术进行保护；
??b）建立运行、监测和报告流程，支持技术基础设施。
动态访问管理系统应通过以下方式保护信息：
??a）需要身份鉴别、适当的凭证或证书来访问信息；
??b）约束访问，例如在特定的时间范围内（例如在给定日期之后或直到特定日期）；
??c）使用加密来保护信息；
??d）定义信息的打印许可；
??e）记录谁访问了信息以及信息是如何被使用的；
??f）如果检测到滥用信息的企图，则发出警报。
其他信息
动态访问管理技术和其他动态信息保护技术可以支持对信息的保护，即使数据在无法实施传统访问控制的数据来源组织之外共享。它可以应用于包含信息的文档、电子邮件或其他文件，以限制谁可以访问内容以及以什么方式访问。它可以是粒度级别的，并且可以在信息的生命周期中进行调整。
动态访问管理技术不会取代传统的访问管理 [例如，使用访问控制列表] ，但可以添加更多的条件性因素、实时评估、即时数据减少和其他对最敏感信息有用的增强功能。它提供了一种控制组织环境外部访问的方法。动态访问管理技术可以支持事件响应，因为权限可以随时修改或撤销。
ISO/IEC 29146提供了有关访问管理框架的更多信息。
8.4 获取源代码
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 #应用安全 #安全配置 | #保护 |
控制
应对源代码、开发工具和软件库的读写权限进行适当管理。
目的
防止引入未经授权的功能，避免无意或恶意的更改，并维护有价值的知识产权的机密性。
指南
应严格控制对源代码和相关项目（如设计、规格、验证计划和确认计划）以及开发工具（如编译器、构建器、集成工具、测试平台和环境）的访问。
对于源代码，这可以通过控制这种代码的中央存储来实现，最好是在源代码管理系统中。
对源代码的读访问和写访问可以根据人员的角色而有所不同。例如，可以在组织内部广泛地提供对源代码的读访问，但是对源代码的写访问只对特权人员或指定所有者开放。当一个组织中的多个开发人员使用代码组件时，应该实现对集中式代码存储库的读访问。此外，如果在组织内部使用开源代码或第三方代码组件，可以广泛地提供对这种外部代码库的读取权限。但是，写访问仍然应该受到限制。
应考虑以下指南来控制对程序源代码库的访问，以减少计算机程序损坏的可能性：
??a）根据既定程序管理对程序源代码和程序源代码库的访问；
??b）根据业务需求授予对源代码的读写权限，并根据既定程序设法解决修改或滥用的风险；
??c）根据变更控制程序（参见8.32）更新源代码和相关项目，并授予访问源代码的权限，且仅在收到适当授权后执行；
??d）不授权开发者直接访问源代码库，而是通过控制源代码上的活动和授权的开发者工具；
??e）在一个安全的环境中保存程序列表，其读写访问应该被适当地管理和分配；
??f）维护所有访问和所有源代码更改的审计日志。
如果打算发布程序源代码，则应考虑采取额外的控制措施来保证其完整性（如数字签名）。
其他信息
如果对源代码的访问控制不当，源代码可能会被修改，或者开发环境中的某些数据（例如生产数据的副本、配置详细信息）可能会被未经授权的人员检索到。
8.5 安全身份认证
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
控制
应根据信息访问约束和访问控制的专题策略来实施安全的身份认证技术和程序。
目的
在授权访问系统、应用程序和服务时，确保用户或实体得到安全身份认证。
指南
应选择合适的认证技术来证实用户、软件、消息和其他实体所声称的身份。
身份认证的强度应适合访问信息的分类。如果需要强有力的身份鉴别和身份核实，则应使用数字证书、智能卡、令牌或生物识别手段等密码以外的身份验证方法。
用于访问关键信息系统的身份认证信息应伴有的附加身份认证因素（也称为多因素身份认证）。使用多种身份认证因素的组合，例如你知道什么、你拥有什么以及你是什么，可以降低未经授权访问的可能性。多因素身份认证可以与其他技术相结合，根据预定义的规则和模式，在特定情况下要求额外的因素，例如来自异常位置、异常设备或异常时间的访问。
如果生物特征认证信息被侵害，则应该作废。根据使用条件（如潮湿或老化），生物特征认证可能不可用。为了应对这些问题，生物特征认证应该至少伴有一种替代认证技术。
登录到系统或应用程序的过程应设计为最大限度地降低未经授权访问的风险。实施登录程序和技术时，应考虑以下因素：
??a）在登录过程成功完成之前，不显示敏感的系统或应用程序信息，以避免向未经授权的用户提供任何不必要的帮助；
??b）显示一般通知，警告该系统或该应用或该服务应当仅由授权用户访问；
??c）在登录过程中不提供对未授权用户有利的帮助消息（例如，如果出现错误情况，系统不应指示数据的哪一部分是正确的或不正确的）；
??d）仅在完成所有输入数据时验证登录信息；
??e）防止对用户名和密码的暴力登录尝试 [例如，使用完全自动化的公共图灵测试来区分计算机和人类（CAPTCHA），要求在预定次数的失败尝试后重置密码，或在最大次数的错误后阻止用户] ；
??f）记录不成功和成功的尝试；
??g）如果检测到登录控制的潜在尝试或成功违背，则引发安全事件（例如，错误的密码尝试达到一定数量时，向用户和组织的系统管理员发送警报）；
??h）登录成功完成后，在单独的频道上显示或发送以下信息：
??????1）上次成功登录的日期和时间；
??????2）自上次成功登录以来任何不成功登录尝试的详细信息；
??i）输入密码时，不以明文显示密码；在某些情况下，可能需要停用此功能，以便于用户登录（例如，出于可访问性原因或避免因重复错误而阻止用户）；
??j）不要在网络上以明文形式传输密码，以免被网络“嗅探器”程序捕获；
??k）在规定的非活动时间段后终止非活动会话，尤其是在高风险位置，比如组织安全管理之外的公共或外部区域或用户终端设备上；
??l）限制连接持续时间，为高风险应用程序提供额外的安全性，并减少未授权访问的机会。
其他信息
有关实体认证保证的更多信息，请参见ISO/IEC 29115。
8.6 容量管理
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 | #完整性 #可用性 | #识别 #保护 #检测 | #连续性 | #治理与生态系统 #保护 |
控制
应根据当前和预期的容量要求监控和调整资源的使用。
目的
确保信息处理设施、人力资源、办公室和其他设施所需的能力。
指南
应确定信息处理设施、人力资源、办公室和其他设施的能力要求，同时考虑相关系统和流程的业务重要性。
应进行系统调整和监控，以确保并在必要时提高系统的可用性和效率。
组织应对系统和服务进行压力测试，以确认有足够的系统容量来满足峰值性能要求。
检测性控制应该到位，以便在需要的时候指出问题。
对未来的能力需求的预测应考虑新的业务和系统需求，以及组织信息处理能力的当前和预测趋势。
应特别注意采购周期长或成本高的任何资源。因此，管理者、服务或产品所有者应该监控关键系统资源的利用率。
管理者应使用容量信息来识别和避免潜在的资源限制和对关键人员的依赖，因为这些可能会对系统安全或服务造成威胁，并计划适当的措施。
可以通过增加容量或减少需求来提供足够的容量。应考虑以下因素来增加容量：
??a）雇佣新员工；
??b）获得新的设施或空间；
??c）获得更强大的处理系统、内存和存储；
??d）利用云计算，云计算具有直接解决容量问题的固有特性。云计算具有弹性和可扩展性，能够按需快速扩展或削减特定应用程序和服务的可用资源。
为减少对组织资源的需求，应考虑以下因素：
??a）删除过时数据（磁盘空间）；
??b）作废已达到保存期的硬拷贝记录（释放搁置空间）；
??c）应用程序、系统、数据库或环境的退役；
??d）优化批处理过程和时间表；
??e）优化应用程序代码或数据库查询；
??f）如果消耗资源的服务不是关键的（例如视频流），拒绝或限制其带宽。
对于任务关键型系统，应考虑记录容量管理计划。
其他信息
有关云计算的弹性和可扩展性的更多详细信息，请参见ISO/IEC TS 23167。
8.7 防范恶意软件
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #检测 | #系统和网络安全 #信息保护 | #保护 #防御 |
控制
应实施针对恶意软件的防护，并籍由适当的用户意识来支持。
目的
确保信息和其他相关资产免受恶意软件的侵害。
指南
针对恶意软件的防护应基于恶意软件检测和修复软件、信息安全意识、适当的系统访问和变更管理控制。单独使用恶意软件检测和修复软件通常是不够的。应考虑以下指南：
??a）实施防止或检测未授权软件使用的规则和控制措施 [例如应用程序允许列表（即使用提供允许应用程序的列表）] （参见8.19和8.32）；
??b）实施控制措施，防止或检测已知或可疑恶意网站的使用（如黑名单）。
??c）减少可能被恶意软件利用的漏洞 [例如，通过技术漏洞管理（参见8.8和8.19）] ；
??d）对系统的软件和数据内容进行定期自动验证，特别是对支持关键业务流程的系统；调查是否存在任何未经批准的文件或未经授权的修订；
??e）针对从外部网络或通过外部网络或任何其他介质获取文件和软件的相关风险，制定保护措施；
??f）安装并定期更新恶意软件检测和修复软件，以扫描计算机和电子存储介质。执行定期扫描并包括：
??????1）在使用之前，对通过网络或任何形式的电子存储介质接收的任何数据进行恶意软件扫描；
??????2）使用前扫描电子邮件和即时消息附件和下载的恶意软件。在不同地点（如电子邮件服务器、台式计算机）和进入组织网络时进行扫描；
??????3）访问网页时扫描网页中的恶意软件；
??g）基于风险评估结果确定恶意软件检测和修复工具的放置和配置，并考虑：
??????1）最有效的纵深防御原则。例如，在网络网关（在诸如电子邮件、文件传输和web的各种应用协议中）以及用户终端设备和服务器中的恶意软件检测；
??????2）攻击者发送恶意软件的规避技术（如使用加密文件）或使用加密协议传播恶意软件；
??h）注意防止在维护和紧急程序中引入恶意软件，这可能绕过针对恶意软件的正常控制；
??i）实施一个流程来授权临时或永久禁用针对恶意软件的部分或全部措施，包括例外批准权限、记录的理由和审查日期。当针对恶意软件的防护导致正常操作中断时，这可能是必要的；
??j）为从恶意软件攻击中恢复而准备适当的业务连续性计划，包括所有必要的数据和软件备份（包括在线和离线备份）以及恢复措施（参见8.13）。
??k）隔离可能发生灾难性后果的环境；
??l）定义程序和责任，以处理系统上的恶意软件防护，包括使用培训、报告和从恶意软件攻击中恢复；
??m）向所有用户提供关于如何识别和潜在减少接收、发送或安装受恶意软件感染的电子邮件、文件或程序的意识或培训（参见6.3） [n）和o）中收集的信息可用于确保意识和培训保持最新] ；
??n）实施定期收集新恶意软件信息的程序，例如订阅邮件列表或查看相关网站；
??o）验证与恶意软件相关的信息（如警告公告）来自合格且信誉良好的来源（如可靠的互联网网站或恶意软件检测软件供应商），并且准确、详实。
其他信息
在一些系统（例如，一些工业控制系统）上安装防止恶意软件的软件并不总是可行的。某些形式的恶意软件会感染计算机操作系统和计算机固件，使得常见的恶意软件控制无法清除系统和操作系统软件的完全重新映像，有时计算机固件需要返回到安全状态。
8.8 技术漏洞的管理
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #威胁和漏洞管理 | #治理和生态系统 #保护 #防御 |
控制
应当获取有关正在使用的信息系统的技术漏洞的信息，应当评估组织暴露于此类漏洞的风险，并采取适当的措施。
目的
防止利用技术漏洞。
指南
识别技术漏洞
组织应该有一份准确的资产清单（参见5.9至5.14），作为有效的技术漏洞管理的先决条件；清单应包括软件供应商、软件名称、版本号、当前部署状态（例如，什么软件安装在什么系统上）以及组织内负责软件的人员。
为了识别技术漏洞，组织应该考虑：
??a）定义和建立与技术漏洞管理相关的角色和职责，包括漏洞监控、漏洞风险评估、更新、资产跟踪和所需的任何协调职责；
??b）对于软件和其他技术（基于资产清单，见5.9），识别用于识别相关技术漏洞的信息资源，并保持对这些漏洞的了解。基于目录中的变化或当发现其他新的或有用的资源时，更新信息资源的列表；
??c）要求信息系统（包括其组件）的供应商确保漏洞报告、处理和披露，包括适用合同中的要求（参见5.20）；
??d）使用适用于所用技术的漏洞扫描工具来识别漏洞，并验证漏洞修补是否成功；
??e）由合格的授权人员进行有计划的、有记录的和可重现的渗透测试或漏洞评估，以支持漏洞的识别。谨慎行事，此类活动可能会危及系统的安全性；
??f）跟踪漏洞的第三方库和源代码的使用。这应该包含在“安全编码”控制项中（参见8.28）。
组织应当开发程序和能力，以便：
??a）检测其产品和服务中存在的漏洞，包括这些产品和服务中使用的任何外部组件；
??b）从内部或外部来源接收漏洞报告。
组织应该提供一个公共联系点，作为漏洞披露的专题策略的一部分，以便研究人员和其他人能够报告问题。组织应建立漏洞报告程序、在线报告表格，并利用适当的威胁情报或信息共享论坛。组织也可考虑bug奖励计划，提供奖赏作为激励，帮助组织识别弱点，以便适当地补救它们。组织还应当与行业主管机构或其他相关方共享信息。
评估技术漏洞
要评估已识别的技术漏洞，应考虑以下指导：
??a）分析并核实报告，以确定需要采取何种应对和补救措施；
??b）一旦确定了潜在的技术漏洞，就要确定相关的风险和要采取的措施。此类操作可能涉及更新易受攻击的系统或应用其他控制措施。
采取适当措施解决技术漏洞
应实施软件更新管理流程，以确保为所有授权软件安装最新批准的补丁程序和应用程序更新。如果需要更改，应保留原始软件，并将更改应用于指定的副本。所有的更改都应该经过充分的测试和记录，以便在必要时可以重新应用到未来的软件升级中。如果需要，更改应由独立的评估机构进行测试和验证。
应考虑以下指南来解决技术漏洞：
??a）针对潜在技术漏洞的识别采取适当和及时的行动；确定对潜在相关技术漏洞通知做出反应的时间表；
??b）根据需要解决技术漏洞的紧急程度，根据与变更管理相关的控制措施（参见8.32）或通过遵循信息安全事件响应程序（参见5.26）来采取行动；
??c）仅使用来自合法来源（可以是组织内部或外部）的更新；
??d）在安装更新之前对其进行测试和评估，以确保它们是有效的，并且不会导致不可容忍的副作用 [即，如果有更新，则评估与安装更新相关的风险（漏洞造成的风险应与安装该更新的风险进行比较）] ；
??e）首先处理高风险系统；
??f）制定补救措施（通常是软件更新或补丁）；
??g）测试以确认补救或缓解措施是否有效；
??h）提供核实补救措施真实性的机制；
??i）如果没有可用的更新或无法安装更新，请考虑其他控制措施，例如：
??????1）应用软件供应商或其他相关来源建议的任何解决方法；
??????2）关闭与漏洞相关的服务或功能；
??????3）在网络边界调整或增加访问控制（如防火墙）（参见8.20至8.22）；
??????4）通过部署合适的流量过滤器（有时称为虚拟补丁）保护易受攻击的系统、设备或应用程序免受攻击；
??????5）加强监测，及时发现实际攻击；
??????6）提高对脆弱性的意识。
对于成品软件，如果供应商定期发布有关其软件安全更新的信息，并提供自动安装此类更新的工具，则组织应决定是否使用自动更新。
其他考虑因素
应该为技术漏洞管理中采取的所有步骤保留审计日志。
应定期监控和评估技术漏洞管理流程，以确保其有效性和效率。
有效的技术漏洞管理流程应与事故管理活动保持一致，以便向事故响应职能部门传达漏洞数据，并提供在事故发生时要执行的技术程序。
如果组织使用第三方云服务提供商提供的云服务，云服务提供商应确保云服务提供商资源的技术漏洞管理。云服务提供商对技术漏洞管理的责任应该是云服务协议的一部分，并应包括报告云服务提供商与技术漏洞相关的行动的流程（参见5.23）。对于某些云服务，云服务提供商和云服务客户有各自的责任。例如，云服务客户负责其用于云服务的自有资产的漏洞管理。
其他信息
技术漏洞管理可以被视为变更管理的子功能，因此可以利用变更管理流程和程序（参见8.32）。
更新可能无法充分解决问题，并产生负面影响。此外，在某些情况下，一旦应用了更新，就很难卸载更新。
如果不可能对更新进行充分的测试（例如，由于成本或缺乏资源），可以考虑延迟更新，以根据其他用户报告的经验评估相关风险。从ISO/IEC 27031可获得有益指导。
如果组织产出软件补丁或更新，可以考虑提供自动更新流程，将这些更新安装在受影响的系统或产品上，而无需客户或用户的干预。如果提供自动更新过程，应允许客户或用户选择关闭自动更新或控制更新安装时间的选项。
如果供应商提供了自动更新流程，并且无需干预即可在受影响的系统或产品上安装更新，则组织将确定是否应用自动流程。不选择自动更新的一个原因是保留对何时执行更新的控制。例如，在业务操作完成之前，不能更新用于业务操作的软件。
漏洞扫描的一个缺点是，它可能没有完全考虑深度防御：如果总是按顺序触发两个措施，可能其中一个措施的漏洞被另一措施的优势所掩盖。漏洞扫描器可能报告漏洞的两个组件，复合起效后可能不显现脆弱性。因此，组织应谨慎审查和处理漏洞报告。
许多组织不仅在组织内部提供软件、系统、产品和服务，而且还向客户、合作伙伴或其他用户等相关方提供。这些软件、系统、产品和服务可能存在影响用户安全的信息安全漏洞。
组织可以发布补救措施并向用户披露有关漏洞的信息（通常通过公共公告），并为软件漏洞数据库服务提供适当的信息。
有关使用云计算时管理技术漏洞的更多信息，请参见ISO/IEC 19086系列和ISO/IEC 27017。
ISO/IEC 29147提供了有关接收漏洞报告和发布漏洞公告的详细信息。ISO/IEC 30111提供了有关处理和解决已报告漏洞的详细信息。
8.9 配置管理
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #安全配置 | #保护 |
控制
应建立、记录、实施、监控和审查硬件、软件、服务和网络的配置，包括安全配置。
目的
确保硬件、软件、服务和网络在所需的安全设置下正常运行，并且配置不会因未经授权或不正确的更改而改变。
指南
常规
组织应定义并实施流程和工具，以在硬件、软件、服务（例如云服务）和网络、新安装的系统以及运营系统的生命周期内强制实施已定义的配置（包括安全配置）。
角色、职责和程序应到位，以确保对所有配置更改的恰当控制。
标准模板
应定义硬件、软件、服务和网络安全配置的标准模板：
??a）使用公开可用的指南（例如，来自供应商和独立安全组织的预定义模板）；
??b）考虑所需的保护级别，以确定足够的安全级别；
??c）支持组织的信息安全策略、专题策略、标准和其他安全要求；
??d）考虑组织环境中安全配置的可行性和适用性。
当需要应对新的威胁或漏洞时，或者当引入新的软件或硬件版本时，应定期审查和更新这些模板。
为硬件、软件、服务和网络的安全配置建立标准模板时，应顾及以下事项：
??a）最小化具有特权或管理员级别访问权限的身份的数量；
??b）禁用不必要、未使用或不安全的身份；
??c）禁用或限制不必要的功能和服务；
??d）约束对高权能的实用程序和主机参数设置的访问；
??e）同步时钟；
??f）安装后立即更改供应商默认验证信息，如默认密码，并检查其他与安全相关的重要参数的默认值；
??g）调用超时工具，该工具在预定的不活动时段之后自动注销计算设备；
??h）验证是否符合许可证要求（参见5.32）。
管理配置
应当记录硬件、软件、服务和网络的既定配置，并且应当维护所有配置更改的日志。记录应安全存放。这可以通过多种方式实现，例如配置数据库或配置模板。
配置变更应遵循变更管理流程（参见8.32）。相关的配置记录可包含：
??a）资产的最新所有者或联系人信息；
??b）上次更改配置的日期；
??c）配置模板的版本；
??d）与其他资产配置的关系。
监控配置
应使用一套全面的系统管理工具（例如维护实用程序、远程支持、企业管理工具、备份和恢复软件）来监控配置，并应定期审查配置，以验证配置设置、评估密码强度并评估所执行的活动。实际配置可以与定义的目标模板进行比较。任何偏差都应纠正，可以自动执行已定义的目标配置，或人工分析偏差并采取纠正措施。
其他信息
系统文档通常记录硬件和软件配置的详细信息。
系统强化是配置管理的一个典型部分。
配置管理可以与资产管理过程和相关工具集成。
自动化通常能更有效地管理安全配置（例如，将基础架构用作代码）。
配置模板和目标可能是机密信息，因此应该防止未经授权的访问。
8.10 信息删除
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 | #保护 | #信息保护 #法律与合规性 | #保护 |
控制
当不再需要时，应删除存储在信息系统、设备或任何其他存储介质中的信息。
目的
防止敏感信息的不必要暴露，并遵守法律、法规、监管和合同对信息删除的要求。
指南
常规
敏感信息的保留时间不应超过降低不当披露风险所需的时间。
删除有关系统、应用程序和服务的信息时，应考虑以下事项：
??a）根据业务要求并考虑相关法律法规，选择删除方法（如电子覆盖或加密擦除）；
??b）记录删除结果作为证据；
??c）当由供应商提供信息删除服务时，从他们那里获取信息删除的证据。
如果第三方代表组织存储本组织的信息，应考虑在第三方协议中纳入删除信息的要求，以便在此类服务终止时强制执行。
删除方法
根据组织关于数据保留的专题策略，并考虑到相关法律法规，应通过以下方式删除不再需要的敏感信息：
??a）将系统配置为在不再需要时安全销毁信息（例如，根据数据保留的专题策略或根据主体访问请求，在规定的时间段之后）；
??b）删除淘汰的版本、副本和临时文件，无论它们位于何处；
??c）使用经批准的安全删除软件来永久删除信息，以帮助确保无法使用专业恢复或取证工具恢复信息；
??d）使用经批准、认证的安全作废服务提供商；
??e）使用适合需作废的存储介质类型的作废机制（例如，消磁硬盘驱动器和其他磁性存储介质）。
在使用云服务的情况下，组织应该验证云服务提供商提供的删除方法是否可接受，如果可以接受，组织应使用该方法，或者要求云服务提供商删除该信息。如果可用且适用，符合专题策略的删除过程应实现自动化。根据所删除信息的敏感性，日志可以跟踪或验证这些删除过程是否已经发生。
为了避免在将设备退回给供应商时无意中暴露敏感信息，应在设备离开组织场所之前，通过移除辅助存储设备（例如硬盘驱动器）和内存来保护敏感信息。
考虑到某些设备（如智能手机）的安全删除只能通过销毁或使用这些设备中嵌入的功能（如“恢复出厂设置”）来实现，组织应根据这些设备所处理的信息的分类选择适当的方法。
应使用7.14中描述的控制措施对存储设备实施物理销毁，同时删除其中包含的信息。
在分析可能的信息泄露事件的原因时，信息删除的正式记录非常有用。
其他信息
关于云服务中用户数据删除的指导参见ISO/IEC 27017。关于删除PII的内容可以在ISO/IEC 27555中找到。
8.11 数据遮盖
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 | #保护 | #信息保护 | #保护 |
控制
应根据组织访问控制和其他相关的专题策略、业务需求和适用的法律，实施数据遮盖。
目的
限制包括PII在内的敏感数据的暴露，并遵守法律、法规、监管和合同要求。
指南
如果需要保护敏感数据（例如PII），组织应考虑使用数据遮盖、假名化或匿名化等技术来隐藏此类数据。
假名化或匿名化技术可以隐藏PII，掩饰PII主体的真实身份或其他敏感信息，并切断PII与PII主体身份之间的联系或其他敏感信息之间的联系。
当使用假名化或匿名化技术时，应验证数据已被充分地假名化或匿名化。数据匿名化应该考虑敏感信息的所有元素才有效。例如，如果考虑不当，即使可以直接识别某个人的数据被匿名化，也可以通过能间接识别个人的其他数据辨别出他来。
数据遮盖的其他技术包括：
??a）加密（要求授权用户拥有密钥）；
??b）取消或删除字符（防止未经授权的用户看到完整的消息）；
??c）变化的数字和日期；
??d）替代（将一个值改为另一个值以隐藏敏感数据）；
??e）用哈希值替换原值。
实施数据遮盖技术时，应考虑以下几点：
??a）不是所有用户都能访问所有数据，因此应设计查询和掩码，以便只向用户显示最低限度的所需数据；
??b）有些情况下，对于一组数据中的某些记录，某些数据不应该对用户可见；在这种情况下，设计并实施一种用于模糊数据的机制（例如，如果患者不希望医院工作人员能够看到他们的所有记录，即使在紧急情况下，医院工作人员也只会看到部分模糊的数据，并且如果数据中包含对于适当施治有用的信息，也只能由具有特定角色的工作人员才能访问数据）；
??c）当数据被模糊时，给予PII委托人要求用户不能看到数据是否被模糊的可能性（即模糊的模糊；这在卫生机构中使用，例如，如果患者不希望工作人员看到诸如怀孕或血液检查结果的敏感信息已经被模糊化了）；
??d）任何法律或法规要求（例如，要求在处理或存储过程中屏蔽支付卡的信息）。
使用数据遮盖、假名化或匿名化时，应考虑以下事项：
??a）根据所处理数据的用途，数据遮盖、假名化或匿名化的强度级别；
??b）对已处理数据的访问控制；
??c）关于使用已处理数据的协议或限制；
??d）禁止将经处理的数据与其他信息进行比较以识别PII主体；
??e）持续跟踪对处理后的数据的提供和接收。
其他信息
匿名化不可逆转地改变了PII，以至于无法直接或间接地识别PII的主体。
假名化用别名替换识别信息。用于执行假名化的算法的知识（有时称为“附加信息”）允许至少某种形式的对PII主体的识别。因此，此类“附加信息”应单独保存并受到保护。
虽然假名化因此比匿名化弱，但假名化数据集在统计研究中可能更有用。
数据遮盖是一套隐藏、替换或混淆敏感数据项的技术。数据遮盖可以是静态的（当数据项在原始数据库中被屏蔽时）、动态的（使用自动化和规则来实时保护数据）或动态的（在应用程序的内存中遮盖数据）。
可以使用散列函数来匿名化PII。为了防止枚举攻击，它们应该总是与salt函数结合使用。
资源标识符及其属性 [例如，文件名、统一资源定位符（URLs）] 中的PII应该避免或适当地匿名化。
有关公共云中PII保护的附加控制在ISO/IEC 27018中给出。
ISO/IEC 20889提供了关于去识别技术的更多信息。
8.12 防止数据泄漏
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 | #保密性 | #保护 #检测 | #信息保护 | #保护 #防御 |
控制
防止数据泄露的措施应适用于处理、存储或传输敏感信息的系统、网络和任何其他设备。
目的
检测并防止个人或系统未经授权披露和提取信息。
指南
组织应考虑以下因素来降低数据泄露的风险：
??a）识别和分类信息以防止泄露（如个人信息、定价模式和产品设计）。
??b）监控数据泄露的渠道（如电子邮件、文件传输、移动设备和便携式存储设备）；
??c）采取措施防止信息泄露（例如，隔离包含敏感信息的电子邮件）。
应使用数据防泄漏工具以：
??a）识别和监控面临未授权披露风险的敏感信息（例如，用户系统上的非结构化数据）。
??b）检测敏感信息的泄露（例如，当信息被上传到不受信任的第三方云服务或通过电子邮件发送时）；
??c）阻止暴露敏感信息的用户操作或网络传输（例如，防止将数据库条目复制到电子表格中）。
组织应确定是否有必要限制用户向组织外部的服务、设备和存储介质复制、粘贴或上传数据的能力。如果是这种情况，组织应实施数据防泄漏工具等技术；或者配置现有工具，使用户能够查看和操作远程保存的数据，但防止在组织控制范围之外进行复制和粘贴。
如果需要数据导出，应使数据所有者有权审批导出，并让用户对其行为负责。
应通过使用条款和条件、培训和审计来解决屏幕截图或拍照的问题。
在备份数据时，应注意确保使用加密、访问控制和保存备份的存储介质的物理保护等措施来保护敏感信息。
数据防泄漏还应考虑用于防止对手获取机密或秘密信息（地缘政治、人力、金融、商业、科学或任何其他信息）的情报行动，这些信息可能对间谍活动有意义，或者对社会至关重要。数据防泄漏措施应着眼于混淆对手的决策，例如，通过用虚假信息替换真实信息，作为独立措施或作为对对手情报行动的回应。这类行为的例子有逆向社会工程或利用蜜罐吸引攻击者。
其他信息
数据防泄漏工具旨在识别数据、监控数据使用和移动，并采取措施防止数据泄漏（例如，提醒用户注意其危险行为，并阻止数据传输到便携式存储设备）。
数据防泄漏本质上涉及监控人员的通信和在线活动，并延伸到外部方消息，这提出了在部署数据防泄漏工具之前应该考虑的法律问题。关于隐私、数据保护、就业、数据截取和电信，有多个立法适用于数据防泄漏背景下的监测和数据处理。
数据防泄漏可以由标准的安全控制来支持，例如关于访问控制和安全文档管理的专题策略（参见5.12和5.15）。
8.13 信息备份
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #纠正性 | #完整性 #可用性 | #恢复 | #连续性 | #保护 |
控制
应根据已获批准的备份相关专题策略，维护和定期测试信息、软件和系统的备份副本。
目的
能够从数据或系统失效中恢复。
指南
应制定备份相关专题策略，以满足组织的数据保留和信息安全要求。
应提供足够的备份设施，以确保在存储介质发生事故、故障或丢失后，可以恢复所有重要信息和软件。
应针对组织如何备份信息、软件和系统制定和实施计划，以满足关于备份的专题策略。
设计备份计划时，应考虑以下事项：
??a）制作备份副本的准确和完整记录，并记录恢复程序；
??b）反映组织的业务要求（如恢复点目标，参见5.30）、所涉及信息的安全要求以及信息在备份范围（如完整或差异备份）和频率方面对组织持续运营的重要性；
??c）将备份存储在安全可靠的远程位置，距离足以使在主站点发生的灾难不会对备份造成的任何损害；
??d）为备份信息提供适当级别的物理和环境保护，与主站点适用的标准相一致（参见第7条和第8.1条）；
??e）定期测试备份介质，以确保在紧急情况下可以视必要使用。测试将备份数据恢复到测试系统的能力，而不是覆盖原始存储介质，以防备份或恢复过程失败并导致不可挽回的数据损坏或丢失；
??f）根据已识别的风险，使用加密措施保护备份（例如，在保密性非常重要的情况下）；
??g）注意确保在进行备份之前检测是否存在意外的数据丢失。
操作程序应监控备份的执行情况，并根据备份相关专题策略解决计划备份的故障，以确保备份的完整性。
应定期测试单个系统和服务的备份措施，以确保它们符合事故响应和业务连续性计划的目标（参见5.30）。这应与恢复程序测试相结合，并根据业务连续性计划要求的恢复时间进行检查。对于关键系统和服务，备份措施应涵盖在发生灾难时恢复整个系统所需的所有系统信息、应用程序和数据。
当组织使用云服务时，应在云服务环境中备份组织的信息、应用程序和系统。当使用作为云服务的一部分提供的信息备份服务时，组织应确定是否以及如何满足备份要求。
应确定重要业务信息的保留期限，并考虑保留归档副本的任何要求。一旦信息的保留期到期，组织应结合法律法规要求，考虑删除用于备份的存储介质中的信息（参见8.10）。
其他信息
有关存储安全性（包括保留考虑）的更多信息，请参见ISO/IEC 27040。
8.14 信息处理设备的冗余
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #可用性 | #保护 | #连续性 #资产管理 | #保护 #韧性 |
控制
信息处理设施的实施应具有足够的冗余，以满足可用性要求。
目的
确保信息处理设施的连续运行。
指南
组织应当确定业务服务和信息系统可用性的要求。组织应该设计和实现具有适当冗余的系统体系结构，以满足这些要求。
可以通过部分或全部复制信息处理设施（即备用部件或所有设施都有两份）来引入冗余。组织应当策划和实施激活冗余组件和处理设施的程序。程序应确定冗余组件和处理活动是否总是激活，或在紧急情况下自动或手动激活。冗余组件和信息处理设施应确保与主要组件相同的安全级别。
应建立机制，提醒组织信息处理设施中的任何故障，使之能执行已计划的程序，并能在信息处理设施维修或更换期间持续可用。
组织在实施冗余系统时应考虑以下事项：
??a）与两个或两个以上网络和关键信息处理设施供应商（如互联网服务提供商）签订合同；
??b）使用冗余网络；
??c）使用两个地理位置不同的数据中心，并配备镜像系统；
??d）使用物理上冗余的电源；
??e）使用软件组件的多个并行实例，它们之间具有自动负载平衡（在相同数据中心或不同数据中心的实例之间）；
??f）在系统（如CPU、硬盘、内存）或网络（如防火墙、路由器、交换机）中有重复的组件。
在适用的情况下，最好在生产模式下，应对冗余信息系统进行测试，以确保从一个组件到另一个组件的故障转移能按预期进行。
其他信息
冗余与业务连续性的ICT就绪（参见5.30）之间有着密切的关系，尤其是在要求恢复时间较短的情况下。许多冗余措施可以成为ICT连续性战略和解决方案的一部分。
实施冗余可能会给信息和信息系统的完整性（例如，将数据复制到重复组件的过程可能会引入错误）或保密性（例如，重复组件的安全控制薄弱可能会导致危害）带来风险，在设计信息系统时需要考虑这些风险。
信息处理设施中的冗余通常不会解决由于应用程序中的故障而导致的应用程序不可用的问题。
通过使用公共云计算，有可能在多个独立的物理位置存在多个实时版本的信息处理设施，并在它们之间实现自动故障转移和负载平衡。
ISO/IEC TS 23167中讨论了在云服务环境中提供冗余和自动故障转移的一些技术和技巧。
8.15 日志
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #检测性 | #保密性 #完整性 #可用性 | #检测 | #信息安全事件管理 | #保护 #防御 |
控制
应生成、存储、保护和分析记录活动、异常、故障和其他相关事件的日志。
目的
记录事件，生成证据，确保日志信息的完整性，防止未经授权的访问，识别可能导致事故的信息安全事件并为调查提供支持。
指南
常规
组织应确定创建日志的目的、收集和记录哪些数据、以及保护和处理日志数据的任何特定于日志的要求。这应该记录在日志相关的专题策略中。
适用时，事件日志应包括每个事件的以下内容：
??a）用户ID；
??b）系统活动；
??c）相关事件的日期、时间和细节（如登录和注销）；
??d）设备身份、系统标识符和位置；
??e）网络地址和协议。
记录时应考虑以下事件：
??a）成功和被拒绝的系统访问尝试；
??b）成功和被拒绝的数据和其他资源访问尝试；
??c）系统配置的变化；
??d）特权的使用；
??e）实用程序和应用程序的使用；
??f）访问的文件和访问类型，包括重要数据文件的删除；
??g）门禁系统发出的警报；
??h）安全系统的激活和取消激活，例如反病毒系统和入侵检测系统；
??i）身份的创建、修改或删除；
??j）用户在应用程序中执行的事务。在某些情况下，应用程序是由第三方提供或运行的服务或产品。
所有系统拥有同步的时间源（参见8.17）非常重要，因为这使系统之间的日志关联成为可能，以便对事件进行分析、报警和调查。
保护日志记录
用户，包括那些具有特殊访问权的用户，不应该具有删除或停用他们自己的活动日志的权限。他们有可能在其直接控制下操纵信息处理设备上的日志。因此，有必要保护和检查日志，以维护对特权用户的可问责性。
控制措施应旨在防止对日志信息的未经授权的更改和对日志记录设施的操作问题，包括：
??a）记录的消息类型的变更；
??b）日志文件被编辑或删除；
??c）一旦保存日志文件的存储介质超限，无法记录新的事件或过去记录的事件会被覆盖。
为了保护日志，应考虑使用以下技术：加密哈希，记录在仅允许追加和只读的文件中，记录在公共透明文件中。
由于数据保留的要求，或收集和保留证据的要求，一些审计日志可能需要存档（参见5.28）。
如果组织需要将系统或应用程序日志发送给供应商，以帮助调试或排除错误，则在发送给供应商之前，应尽可能使用数据遮盖技术（参见8.11）对日志进行去标识，如用户名、IP地址、主机名或组织名称等信息。
事件日志可能包含敏感数据和个人身份信息。应采取适当的隐私保护措施（参见5.34）。
日志分析
日志分析应涵盖对信息安全事件的分析和解释，以帮助识别异常活动或异常行为，这些活动或行为可能代表着危害。
事件分析应考虑以下因素：
??a）进行分析的专家的必要技能；
??b）确定日志分析的程序；
??c）每个安全相关事件所需的属性；
??d）通过使用预定规则识别的例外情况 [例如，安全信息与事件管理（SIEM）或防火墙规则，以及入侵检测系统（IDSs）或恶意软件签名] ；
??e）与异常活动和行为相比较的已知行为模式和标准网络流量 [用户和实体行为分析（UEBA）] ；
??f）趋势或模式分析的结果（例如，使用数据分析、大数据技术和专业分析工具的结果）；
??g）可用的威胁情报。
日志分析应得到特定监控活动的支持，以帮助识别和分析异常行为，包括：
??a）审查对受保护资源的成功和不成功的访问尝试 [例如，域名系统（DNS）服务器、网络门户和文件共享] ；
??b）检查DNS日志以识别到恶意服务器的出站网络连接，例如那些与僵尸网络命令和控制服务器相关联的连接；
??c）检查来自服务提供商的使用报告（例如费用清单或服务报告），以发现系统和网络中的异常活动（例如通过审查活动模式）；
??d）结合物理监控的事件日志，如入口和出口，以确保更准确的检测和事件分析；
??e）关联日志以实现高效和高度准确的分析。
应识别可疑和实际的信息安全事件（如恶意软件感染或防火墙探测）并接受进一步调查（如作为信息安全事件管理流程的一部分，参见5.25）。
其他信息
系统日志通常包含大量信息，其中大部分与信息安全监控无关。为了帮助识别用于信息安全监控目的的重要事件，可以考虑使用合适的实用程序或审计工具来执行文件盘查。
事件记录为自动监控系统（参见8.16）奠定了基础，自动监控系统能够生成关于系统安全的综合报告和警报。
SIEM工具或等效服务可用于存储、关联、标准化和分析日志信息，并生成警报。SIEM往往需要仔细配置，以发挥其优势。要考虑的配置包括：识别和选择适当的日志源，调整和测试规则，以及开发用例。
用于记录日志的公共透明文件可以提供额外的检测机制，有助于防止日志篡改。例如在证书透明系统中那样。
在云环境中，日志管理责任可以在云服务客户和云服务提供商之间共享。根据所使用的云服务类型，职责会有所不同。进一步的指南可以在ISO/IEC 27017找到。
8.16 活动监测
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #检测性 #纠正性 | #保密性 #完整性 #可用性 | #检测 #响应 | #信息安全事件管理 | #防御 |
控制
应监控网络、系统和应用程序的异常行为，并采取适当的措施来评估潜在的信息安全事故。
目的
检测异常行为和潜在的信息安全事件。
指南
监控范围和级别应根据业务和信息安全要求确定，并考虑相关法律法规。监控记录应保留规定的保留期。
应考虑将以下内容纳入监控系统：
??a）出站和入站网络、系统和应用流量；
??b）访问系统、服务器、网络设备、监控系统、关键应用程序等。；
??c）关键或管理级系统和网络配置文件；
??d）来自安全工具的日志 [例如，防病毒、IDS、入侵防御系统（IPS）、网络过滤器、防火墙、数据泄漏防护] ；
??e）与系统和网络活动相关的事件日志；
??f）检查正在执行的代码是否被授权在系统中运行，以及它是否被篡改（例如，通过重新编译以添加额外的非预期的代码）；
??g）资源（例如CPU、硬盘、内存、带宽）的使用及其性能。
组织应建立正常行为的基线，并根据该基线监控异常情况。建立基线时，应考虑以下因素：
??a）审查正常和高峰时期的系统利用率；
??b）每个用户或用户组的通常访问时间、访问位置、访问频率。
监控系统应根据确定的基线进行配置，以识别异常行为，例如：
??a）流程或应用程序的意外终止；
??b）通常与来源于已知恶意IP地址或网络范围的恶意软件或流量相关的活动（例如，与僵尸网络命令和控制服务器相关的活动）；
??c）已知的攻击特征（例如拒绝服务和缓冲区溢出）；
??d）异常的系统行为（例如击键记录、进程注入和标准协议使用中的偏差）；
??e）瓶颈和过载（例如网络排队、延迟水平和网络抖动）；
??f）对系统或信息的未经授权的访问（实际的或企图的）；
??g）未经授权扫描业务应用程序、系统和网络；
??h）访问受保护资源（如DNS服务器、门户网站和文件系统）的成功和不成功尝试；
??i）与预期行为相关的、异常的用户和系统行为。
应使用监控工具进行持续监控。根据组织的需要和能力，应实时或定期进行监控。监控工具应具备处理大量数据的能力，适应不断变化的威胁形势，并能够实时通知。这些工具还应该能够识别特定的签名以及数据或网络或应用程序行为模式。
自动化监控软件应配置为基于预定义的阈值生成警报（例如，通过管理控制台、电子邮件或即时消息系统）。警报系统应根据组织的基准进行调整和培训，以最大限度地减少误报。应配置专人响应警报，并应接受适当培训，以准确解释潜在事件。应该有接收和响应警报通知的冗余系统和流程。
异常事件应与相关方沟通，以改进以下活动：审核、安全评估、漏洞扫描和监控（参见5.25）。应建立程序，及时响应来自监控系统的阳性指标，以最大限度地减少不利事件（参见5.26）对信息安全的影响。还应建立识别和解决假阳性的程序，包括调整监控软件以减少未来假阳性的数量。
其他信息
可以通过以下方式增强安全监控：
??a）利用威胁情报系统（参见5.7）；
??b）利用机器学习和人工智能能力；
??c）使用阻止列表或允许列表；
??d）进行一系列技术安全评估（例如，漏洞评估、渗透测试、网络攻击模拟和网络响应演习），并使用这些评估的结果来帮助确定基线或可接受的行为；
??e）使用性能监控系统帮助确定和检测异常行为；
??f）结合监控系统利用日志。
监控活动通常使用专业软件进行，如入侵检测系统。这些可以根据正常、可接受和预期的，系统和网络活动的基线进行配置。
监控异常通信有助于识别僵尸网络（即僵尸网络所有者恶意控制的一组设备，通常用于对其他组织的其他计算机发起分布式拒绝服务攻击）。如果计算机由外部设备控制，则受感染的设备和控制器之间会有通信。因此，组织应该部署技术手段来监控异常通信，并采取必要的措施。
8.17 时钟同步
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #检测性 | #完整性 | #保护 #检测 | #信息安全事件管理 | #保护 #防御 |
控制
组织使用的信息处理系统的时钟应与批准的时间源同步。
目的
实现安全相关事件和其他记录数据的关联和分析，并支持对信息安全事件的调查。
指南
应文件化和实施对时间显示、可靠同步和准确性的外部和内部要求。这些要求可能来自法律、法规、规章、合同、标准和内部监控的需要。应为所有系统定义并考虑在组织内使用的标准参考时间，包括楼宇管理系统、进出系统和其他可用于协助调查的系统。
应使用与国家原子钟或全球定位系统（GPS）的无线电时间广播相关的时钟作为日志系统的参考时钟；一致、可信的日期和时间源，以确保准确的时间戳。应该使用网络时间协议（NTP）或精密时钟协议（PTP）等协议来保持所有联网系统与参考时钟同步。
组织可以同时使用两个外部时间源，以提高外部时钟的可靠性，并适当地管理任何差异。
当使用多个云服务，或同时使用云和内部服务时，时钟同步可能会很困难。在这种情况下，应监控每项服务的时钟并记录差异，以减轻差异带来的风险。
其他信息
正确设置计算机时钟对于确保事件日志的准确性非常重要，这些事件日志可能是调查所必需的，或者是法律和纪律案件的证据。不准确的审计日志会阻碍此类调查，或损害此类证据的可信度。
8.18 特权实用程序的使用
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #系统和网络安全 #安全配置 #应用安全 | #保护 |
控制
应该限制和严格控制能够凌驾系统和应用程序控制的实用程序的使用。
目的
从信息安全的角度，确保实用程序的使用损害系统和应用程序控制。
指南
对于能够凌驾系统和应用程序控制的实用程序的使用，应考虑以下准则：
??a）将实用程序的使用局限于可信的、授权的用户（参见8.2）；
??b）使用实用程序的识别、认证和授权程序，包括使用者的唯一标识；
??c）定义和记录实用程序的授权级别；
??d）授权临时使用实用程序；
??e）如果应用程序运行于要求职责分离的系统上，则该程序和系统的用户不得使用实用程序；
??f）删除或禁用所有不必要的实用程序；
??g）实用程序与应用软件至少应逻辑隔离。在可行的情况下，将实用程序的网络通信与应用程序流量隔离；
??h）限制实用程序的可用性（如授权变更的持续时间）；
??i）所有实用程序的使用应留有日志。
其他信息
大多数信息系统都有一个或多个能够凌驾系统和应用程序控制的实用程序，例如诊断、修补、防病毒、磁盘碎片整理程序、调试器、备份和网络工具。
8.19 在操作系统上安装软件
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全领域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #安全配置 #应用安全 | #保护 |
控制
对于在操作系统上安装软件，应实施程序和措施来安全地管理。
目的
确保运营系统的完整性并防止利用技术漏洞。
指南
为了安全地管理操作系统上的软件更改和安装，应考虑以下准则：
??a）只有经适当管理授权的、训练有素的管理员，才能执行操作软件的更新（参见8.5）；
??b）确保在操作系统上只安装经批准的可执行代码，不安装开发代码或编译器；
??c）仅在广泛和成功的测试后安装和更新软件（参见8.29和8.31）；
??d）更新所有相应的程序的源库；
??e）使用配置控制系统保持对所有操作软件和系统文件的控制；
??f）在实施更改之前定义回滚策略；
??g）维护运营软件所有更新的审计日志；
??h）作为一项应急措施，将旧版本的软件以及所有必需的信息和参数、程序、配置细节和支持软件存档，并在软件需要读取或处理存档数据时存档。
任何升级到新版本的决策都应考虑变更的业务要求和版本的安全性（例如引入新的信息安全功能，或影响当前版本的信息安全漏洞的数量和严重性）。当软件补丁有助于消除或减少信息安全漏洞时，应应用软件补丁（参见8.8和8.19）。
计算机软件可能依赖于外部提供的软件和软件包（例如，使用托管在外部网站上的模块的软件程序），应监控这些软件和软件包以避免未经授权的更改，因为它们可能会引入信息安全漏洞。
操作系统中使用的软件如果是由供应商提供的，应保持在该供应商支持的水平。随着时间的推移，软件供应商会停止支持旧版本的软件。组织应该考虑依赖不受支持的软件的风险。运营系统中使用的开源软件应维护到该软件的最新适当版本。随着时间的推移，开源代码可能停止维护，但仍然可以在开源软件库中使用。组织还应该考虑在操作系统中使用时依赖未经维护的开源软件的风险。
当供应商参与安装或更新软件时，应仅在必要时提供物理或逻辑访问，并获得适当授权。应对供应商的活动进行监控（参见5.22）。
组织应该针对用户可以安装的软件类型定义规则，并严格执行。
操作系统上的软件安装应适用最低特权原则。组织应确定哪些类型的软件安装是允许的（例如，现有软件的更新和安全修补程序）以及哪些类型的安装是禁止的（例如，仅供个人使用的软件以及其潜在恶意来源未知或可疑的软件）。应该根据相关用户的角色授予这些权限。
其他信息
没有其他信息。
8.20 网络安全
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 | #保密性 #完整性 #可用性 | #保护 #检测 | #系统和网络安全 | #保护 |
控制
应对网络和网络设备进行保护、管理和控制，以保护系统和应用程序中的信息。
目的
保护网络中的信息及其支持信息处理设施免受网络危害。
指南
应实施控制措施来确保网络中信息的安全性，并保护连接的服务免受未经授权的访问。特别是，应考虑以下事项：
??a）网络能够支持的信息类型和分类级别；
??b）建立网络设备和装置管理的责任和程序；
??c）维护最新文档，包括网络图和设备配置文件（如路由器、交换机）；
??d）酌情将网络运作责任与ICT系统运作分开（参见5.3）；
??e）建立控制措施，以保护通过公共网络、第三方网络或无线网络传输的数据的机密性和完整性，并保护连接的系统和应用程序（参见5.22、8.24、5.14和6.6）。还可能需要额外的控制来维护网络服务和连接到网络的计算机的可用性；
??f）适当地实施日志和监控，以便能够记录和检测可能影响信息安全或与信息安全相关的行为（参见8.16和8.15）；
??g）紧密的协调网络管理活动，在优化对本组织的服务同时，确保控制措施在整个信息处理架构中得到一致应用；
??h）认证网络上的系统；
??i）限制和过滤系统与网络的连接（例如使用防火墙）；
??j）检测、限制和认证设备和装置到网络的连接；
??k）加固网络设备；
??l）将网络管理信道与其他网络流量隔离；
??m）如果网络受到攻击，临时隔离关键子网（例如使用“吊桥”装置）；
译者注：原文drawbridge指的是那种可以断开并两边拉起，以便高桅船只经过的桥，这里指的应是一种可按需断开或闭合以控制网络连通性的装置。
??n）禁用易受攻击的网络协议。
组织应确保对虚拟化网络的使用应用适当的安全控制。虚拟化网络包括软件定义的网络（SDN、SD-WAN）。从安全角度来看，虚拟化网络可能是可取的，因为它们可以允许在物理网络上发生的通信的逻辑分离，特别是对于使用分布式计算实现的系统和应用。
其他信息
有关网络安全的其他信息参见ISO/IEC 27033系列。有关虚拟化网络的更多信息可以在ISO/IEC TS 23167中找到。
8.21 网络服务的安全性
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #系统和网络安全 | #保护 |
控制
应指明、实施和监控网络服务的安全机制、服务级别和服务要求。
目的
确保网络服务使用的安全性。
指南
应（由内部或外部网络服务提供商）指明和实施特定服务所需的安全措施，如安全功能、服务级别和服务要求。组织应确保网络服务提供商实施这些措施。
应确定并定期监控网络服务提供商以安全方式管理约定的服务的能力。审计权应由组织和供应商共同商定。组织还应考虑由服务提供商提供第三方证明，来证明他们维护了适当的安全措施。
应制定和实施关于使用网络和网络服务的规则，以涵盖：
??a）允许访问的网络和网络服务；
??b）访问各种网络服务的身份鉴别要求；
??c）用于确定谁被允许访问哪些网络和联网服务的授权程序；
??d）保护网络连接和网络服务的网络管理和技术控制及程序；
??e）用于访问网络和网络服务的方式 [例如，使用虚拟专用网络（VPN）或无线网络] ；
??f）用户在访问时的时间、位置和其他属性；
??g）监控网络服务的使用。
应该考虑网络服务的以下安全功能：
??a）应用于网络服务安全的技术，如身份鉴别、加密和网络连接控制；
??b）根据安全和网络连接规则，安全连接到网络服务的技术参数要求；
??c）缓存（例如在内容分发网络中）及其参数，使用户可根据性能、可用性和保密性要求选择缓存的使用；
??d）网络服务使用程序，必要时限制对网络服务或应用程序的访问。
其他信息
网络服务包括提供连接、专网服务、以及托管的网络安全解决方案（如防火墙和入侵检测系统）。这些服务包括从简单的非托管带宽到复杂的增值服务。
ISO/IEC 29146给出了关于访问管理框架的更多指导。
8.22 网络隔离
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #系统和网络安全 | #保护 |
控制
信息服务、用户和信息系统应该在组织的网络中按分组进行隔离。
目的
在安全边界内分割网络，并根据业务需求控制它们之间的流量。
指南
组织应考虑通过将大型网络划分为独立的网络域，并将其与公共网络（如internet）隔离开来，来管理大型网络的安全性。可以根据信任级别、关键程度和敏感度（例如，公共访问域、桌面域、服务器域、低风险和高风险系统）、组织单元（例如，人力资源、财务、营销）或某种组合（例如，连接到多个组织单位的服务器域）来选择域。可以使用物理上不同的网络或者使用不同的逻辑网络来完成隔离。
每个域的边界应该定义明确。如果允许网络域之间的访问，则应使用网关（如防火墙、过滤路由器）在外围进行控制。将网络划分为多个域的标准，以及允许通过网关进行的访问，应该基于对每个域的安全要求的评估。评估应符合关于访问控制的专题策略（参见5.15）、访问需求、所处理信息的价值和分类，并考虑采用合适网关技术的相对成本和性能影响。
由于网络边界不明确，无线网络需要特殊处理。无线网络隔离应考虑无线电波覆盖调整。对于敏感环境，应考虑将所有无线接入视为外部连接，并将该接入与内部网络隔离，直到该接入通过符合网络控制（参见8.20）的网关，然后再授予对内部系统的接入。如果员工仅使用符合组织专题策略的受控用户终端设备，则访客的无线接入网络应与员工的无线接入网络分开。供访客使用的WiFi至少应具有与供员工使用的WiFi相同的限制，以阻止员工使用访客WiFi。
其他信息
因为商业伙伴关系的形成需要信息处理和网络设施的互连或共享，网络常常延伸到组织的边界之外。这种扩展会增加未经授权访问组织联网的信息系统的风险，其中一些信息系统因其敏感性或重要性而需要保护，以免被其他网络用户访问。
8.23 web过滤
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #系统和网络安全 | #保护 |
控制
应管理对外部网站的访问，以减少被恶意内容影响的机会。
目的
保护系统免受恶意软件的危害，并防止访问未经授权的网站资源。
指南
组织应降低其员工访问包含非法信息或已知包含病毒或网络钓鱼材料的网站的风险。实现这一目的的技术是阻止相关网站的IP地址或域。一些浏览器和反恶意软件技术会自动执行此操作，或者可以配置为执行此操作。
组织应确定员工应该或不应该访问的网站类型。组织应考虑阻止对以下类型网站的访问：
??a）具有信息上传功能的网站，除非根据正当的业务理由批准；
??b）已知或可疑的恶意网站（例如，分发恶意软件或网络钓鱼内容的网站）；
??c）C&C服务器；
??d）从威胁情报中获取的恶意网站（参见5.7）；
??e）共享非法内容的网站。
在部署此控制措施之前，组织应建立安全和适当使用在线资源的规则，包括对不受欢迎或不适当的网站和基于web的应用程序的任何限制。这些规则应该维持更新。
应对员工进行安全和适当使用在线资源（包括访问网络）的培训。培训应包括组织的规则、报告安全相关事项的联系人或联系途径、以及出于合法业务原因需要访问受限web资源时的例外流程。还应对员工进行培训，以确保凡是浏览器提示网站不安全但允许用户选择继续访问时，他们不会刻意忽略该提示而继续访问。
其他信息
web过滤可以包括一系列技术，包括签名、启发式、可接受网站或域列表、禁止网站或域列表和定制配置，以帮助防止恶意软件和其他恶意活动攻击组织的网络和系统。
8.24 密码学的使用
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #安全配置 | #保护 |
控制
应定义和实施有效使用加密技术的规则，包括加密密钥管理。
目的
根据业务和信息安全要求，确保正确有效地使用加密技术来保护信息的机密性、真实性或完整性，并考虑与加密技术相关的法律、法规、监管和合同要求。
指南
常规
使用加密时，应考虑以下几点：
??a）组织定义加密相关的专题策略，包括保护信息的一般原则。有必要制定一项关于使用加密技术的专题策略，以最大限度地利用加密技术，最大限度地降低风险，并避免不当或不正确的使用；
??b）确定所需的保护的信息的级别和分类，从而确定所需加密算法的类型、强度和质量；
??c）使用加密技术保护保存在移动用户终端设备或存储介质上的信息，以及通过网络传输到这些设备或存储介质的信息；
??d）密钥管理方法，包括处理加密密钥的生成和保护，以及在密钥丢失、被侵害或损坏的情况下恢复加密信息的方法；
??e）关于以下事务的角色和职责：
??????1） 执行有效使用加密技术的规则；
??????2） 密钥管理，包括密钥生成（参见8.24）；
??f）要采用的标准，以及组织中批准或要求使用的加密算法、加密强度、加密解决方案和使用方法；
??g）使用加密信息对依赖内容检查（例如恶意软件检测或内容过滤）的控制的影响。
在实施组织有效使用加密技术的规则时，应考虑适用于世界不同地区使用加密技术的法规和国家限制，以及加密信息的跨境流动问题（参见5.31）。
与外部加密服务供应商（如认证机构）签订的服务水平协议或合同的内容应涵盖责任、服务可靠性和提供服务的响应时间等问题（参见5.22）。
密钥管理
适当的密钥管理应包括生成、存储、归档、检索、分发、停用和销毁密钥的安全流程。
密钥管理系统应该基于一系列得到批准的标准、程序和安全方法，以：
??a）为不同的密码系统和不同的应用程序生成密钥；
??b）发布和获取公钥证书；
??c）将密钥分发给预期的实体，包括当接收到密钥时如何激活密钥；
??d）存储密钥，包括授权用户如何获取密钥；
??e）更改或更新密钥，包括何时更改密钥以及如何更改的规则；
??f）处理泄露的密钥；
??g）撤销密钥，包括如何撤销或停用密钥 [例如，当密钥已经失密或当用户离开组织时（在这种情况下，密钥也应存档）] ；
??h）恢复丢失或损坏的密钥；
??i）备份或存档密钥；
??j）销毁钥匙；
??k）关键管理相关活动的记录和审计；
??l）设定密钥的激活和停用日期，以便密钥只能在符合组织密钥管理规则的时间段内使用；
??m）处理访问加密密钥的合法请求（例如，可以要求以未加密的形式提供加密信息，作为法庭案件中的证据）。
所有加密密钥都应受到保护，以防修改和丢失。此外，秘钥和私钥需要防止未经授权的使用和泄露。用于生成、存储和归档密钥的设备应受到物理保护。
除了完整性，对于很多使用场景来说，还应该考虑公钥的真实性。
其他信息
公钥的真实性通常由使用认证机构和公钥证书的公钥管理过程来解决，但是也可以通过使用诸如手工操作小数字按键之类的技术来解决。
加密技术可用于实现不同的信息安全目标，例如：
??a）保密性：使用信息加密来保护存储或传输的敏感或关键信息；
??b）完整性或真实性：使用数字签名或消息认证码来验证存储或传输的敏感或关键信息的真实性或完整性。使用算法进行文件完整性检查；
??c）不可否认性：使用密码技术提供事件或行为发生或未发生的证据；
??d）认证：使用加密技术对请求访问系统用户、实体和资源或与之进行交易的用户和其他系统实体进行认证。
ISO/IEC 11770系列提供了有关密钥管理的更多信息。
8.25 安全开发生命周期
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
控制
应该建立和施行软件和系统安全开发的规则。
目的
确保在软件和系统的安全开发生命周期内设计和实施信息安全。
指南
安全开发是构建安全服务、架构、软件和系统的要求。应顾及以下事项：
??a）开发、测试和生产环境的分离（参见8.31）；
??b）软件开发生命周期中的安全性指南：
??????1） 软件开发方法中的安全性（参见8.28和8.27）；
??????2） 所用每种编程语言的安全编码指南（参见8.28）；
??c）规范和设计阶段的安全要求（参见5.8）；
??d）项目中的安全检查点（参见5.8）；
??e）系统和安全测试，如回归测试、代码扫描和渗透测试（参见8.29）；
??f）源代码和配置的安全储存库（参见8.4和8.9）；
??g）版本控制中的安全性（参见8.32）；
??h）所需的应用安全知识和培训（参见8.28）；
??i）开发人员预防、发现和修复漏洞的能力（参见8.28）；
??j）许可要求和替代方案，以确保解决方案的成效益高，同时避免将来的许可问题（参见5.32）。
如果外包开发，组织应当确保供方遵守组织的安全开发规则（参见8.30）。
其他信息
开发也可以在诸如办公应用程序、脚本、浏览器和数据库等应用程序内部进行。
译者注：此处原文“Development can also take place inside applications, such as office applications, scripting, browsers and databases.”我没能真正理解，这句应是翻岔了的，求指正。
8.26 应用程序安全要求
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 #防御 |
控制
在开发或采购应用程序时，应识别、详述和审批信息安全要求。
目的
确保在开发或获取应用程序时，所有信息安全要求都已确定并得到满足。
指南
常规
应该识别和详述应用程序安全要求。这些要求通常通过风险评估来确定。这些要求应在信息安全专家的支持下制定。
根据应用程序的用途，应用程序安全要求可能涵盖广泛的主题。
如果适用，应用程序安全要求应包括：
??a）实体身份的信任级别 [例如，通过身份鉴别（参见5.17、8.2和8.5）] ；
??b）确定应用程序要处理的信息类型和分类级别；
??c）需要分离应用程序中数据和功能的访问权限和访问级别；
??d）抵御恶意攻击或意外中断的能力（例如，防范缓冲区溢出或SQL注入）；
??e）交易被生成、处理、完成或存储时所在的司法管辖区的法律、法规和监管要求；
??f）与所有相关方相关的隐私需求；
??g）任何机密信息的保护要求；
??h）在处理、传输和存放过程中保护数据；
??i）安全地加密所有相关方之间的通信的需求；
??j）输入控制，包括完整性检查和输入验证；
??k）自动化控制（如批准限额或双重批准）。
??l）输出控制，也考虑谁可以访问输出及其授权；
??m）对“自由文本”字段内容的限制，因为这些可能导致机密数据（如个人数据）的不受控制的存储；
??n）源自业务流程的需求，如事务日志和监控、不可否认性的需求；
??o）由其他安全控制措施强制实现的要求（如记录和监控或数据泄漏检测系统的接口）；
??p）错误消息处理。
交易服务
对于在组织和合作伙伴之间提供交易服务的应用程序，在确定信息安全要求时还应考虑以下因素：
??a）各方对彼此声称的身份所要求的信任程度；
??b）交换或处理的信息的完整性所需的信任级别，以及识别完整性缺陷的机制（如循环冗余校验、哈希、数字签名）；
??c）关于谁可以批准内容、发布或签署关键交易文件的授权流程；
??d）保密性、完整性、关键文件的发送和接收证明、以及不可否认性（如与招标和合同流程相关的合同）；
??e）任何交易的保密性和完整性（例如订单、交货地址详情和收据确认）；
??f）对交易保密时间的要求；
??g）保险和其他合同要求。
电子订购和支付应用
对于涉及电子订购和支付的应用程序，还应考虑：
??a）维护订单信息保密性和完整性的要求；
??b）适于验证客户提供的支付信息的校验等级；
??c）避免交易信息的丢失或复制；
??d）不在任何可公开访问的环境中存储交易详细信息（例如，在组织内联网上现有的存储平台上，并且不在可从互联网直接访问的电子存储介质上保留和公开）；
??e）在使用可信机构的情况下（例如，出于发布和维护数字签名或数字证书的目的），安全性被集成并嵌入到整个端到端证书或签名管理过程中。
考虑到法律要求（参见5.31至5.36，特别是5.31关于密码学的立法部分），上述几个考虑事项可以通过应用密码学（参见8.24）来解决。
其他信息
可通过网络访问的应用程序面临一系列与网络相关的威胁，如欺诈活动、合同纠纷或信息公开披露、传输不完整、路由错误、未经授权的消息更改、复制或重放。因此，详细的风险评估和谨慎的控制措施是必不可少的。所需的控制措施通常包括用于验证和保护数据传输的加密方法。
有关应用程序安全性的更多信息可以在ISO/IEC 27034系列中找到。
8.27 安全系统架构和工程原理
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
控制
应建立、记录、维护安全系统工程的原则，并将其应用于任何信息系统开发活动。
目的
确保在开发生命周期中安全地设计、实施和运营信息系统。
指南
应建立、记录安全工程原则，并将其应用于信息系统工程活动。所有架构层（业务、数据、应用和技术）都应设计安全性。应对新技术进行安全风险分析，并根据已知的攻击模式审查设计。
安全工程原则提供了有关用户身份验证技术、安全会话控制以及数据验证和清理的指导。
安全系统工程原则应包括以下分析：
??a）保护信息和系统免受已知威胁所需的全方位安全控制措施；
??b）安全控制预防、检测或响应安全事件的能力；
??c）特定业务流程所需的特定安全控制措施（如敏感信息加密、完整性检查和信息的数字签名）。
??d）在何处以及如何应用安全控制（例如，通过与安全架构和技术基础设施集成）；
??e）多个独立的安全控制（手动和自动）如何协同工作以产生一组综合的控制。
安全工程原则应考虑到：
??a）与安全架构集成的需求；
??b）技术性安全基础设施 [例如公钥基础设施（PKI）、身份和访问管理（IAM）、数据泄漏预防和动态访问管理] ；
??c）组织开发和支持所选技术的能力；
??d）满足安全要求的成本、时间和复杂性；
??e）当前的良好实践。
安全系统工程应包括：
??a）安全架构原则的使用，如“设计安全”、“纵深防御”、“默认安全”、“默认拒绝”、“安全地失败”、“不信任来自外部应用程序的输入”、“部署中的安全”、“假定违背”、“最低权限”、“可用性和可管理性”以及“最小化功能”；
??b）以安全为导向的设计审查，以帮助识别信息安全漏洞，确保安全控制措施得到规定并满足安全要求；
??c）不完全符合要求的安全控制措施的文件记录和正式确认（例如，由于压倒一切的人身安全要求）；
??d）系统加固
组织应考虑“零信任”原则，例如：
??a）假设组织的信息系统已经遭受违背，因此不能只依赖网络边界安全；
??b）对信息系统的访问采用“永远不信任，永远验证”的方法；
??c）确保对信息系统的请求是端到端加密的；
??d）对信息系统的每个请求进行验证，就像这些请求来自开放的外部网络一样，即使这些请求来自组织内部（即不会自动信任其边界内外的任何内容）；
??e）使用“最低特权”和动态访问控制技术（参见5.15、5.18和8.2）。这包括基于诸如身份鉴别信息（参见5.17）、用户身份（参见5.16）、关于用户终端设备的数据和数据分类（参见5.12）之类的上下文信息来认证和授权对信息或系统的请求；
??f）始终对请求者进行身份验证，并始终根据包括身份鉴别信息（5.17）和用户身份（5.16）、关于用户终端设备的数据和数据分类（参见5.12）在内的信息来验证对信息系统的授权请求，例如强制实施强身份验证（例如，多因素，参见8.5）。
在适用的情况下，应通过组织与外包供应商之间的合同和其他有约束力的协议，将既定的安全工程原则应用于信息系统的外包开发。组织应确保供应商的安全工程实践符合组织的需求。
应定期审查安全工程原则和既定的工程程序，以确保它们有效促进提高工程过程中的安全标准。还应定期审查它们，以确保它们在应对任何新的潜在威胁方面保持最新，并适用于正在应用的技术和解决方案的进步。
其他信息
安全工程原则可应用于一系列技术的设计或配置，例如：
??????— 容错和其他弹性技术；
??????— 隔离（例如通过虚拟化或集装箱化）；
??????— 防篡改。
安全虚拟化技术可用于防止在同一物理设备上运行的应用程序之间的干扰。如果应用程序的虚拟实例被攻击者破坏，只有该实例会受到影响。这种攻击对任何其他应用程序或数据都没有影响。
防篡改技术可用于检测信息容器的篡改，无论是物理的（例如防盗报警器）还是逻辑的（例如数据文件）。这种技术的一个特征是有篡改容器的企图的记录。此外，该控制可以通过自销毁（例如，可以删除设备内存）来阻止数据的成功提取。
8.28 安全编码
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全领域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
控制
软件开发中应该应用安全编码原则。
目的
确保安全的编写软件，从而减少软件中潜在的信息安全漏洞。
指南
常规
组织应该建立全组织范围适用的过程，为安全编码提供良好的治理。应建立并应用最低限度的安全基线。此外，这种过程和治理应该扩展到包括来自第三方的软件组件和开源软件。
组织应监控真实世界的威胁以及关于软件漏洞的最新建议和信息，从而通过持续改进和学习来指导组织的安全编码原则。这有助于确保实施有效的安全编码实践，以应对快速变化的威胁形势。
规划和编码前
安全编码原则应该用于新的开发和重用场景。这些原则应当适用于组织内部的开发活动以及组织向他人提供的产品和服务。编码前的规划和先决条件应包括：
??a）组织特定的期望和批准的安全编码原则，用于内部和外包代码开发；
??b）导致信息安全漏洞的常见和历史编码实践和缺陷；
??c）配置开发工具，如集成开发环境（IDE），以帮助强制创建安全代码；
??d）遵循开发工具和执行环境提供商发布的适用指南；
??e）维护和使用更新的开发工具（如编译器）；
??f）编写安全代码的开发人员的资格；
??g）安全设计和架构，包括威胁建模；
??h）安全编码标准，并在相关情况下授权其使用。
??i）使用受控环境进行开发。
编码期间
编码期间的考虑因素应包括：
??a）特定于正在使用的编程语言和技术的安全编码实践；
??b）使用安全编程技术，如结对编程、重构、同行评审、安全迭代和测试驱动开发；
??c）使用结构化编程技术；
??d）记录代码并消除可能导致信息安全漏洞被利用的编程缺陷；
??e）禁止使用不安全的设计技术（例如，使用硬编码密码、未经批准的代码样本和未经认证的web服务）。
测试应在开发期间和之后进行（参见8.29）。静态应用程序安全测试（SAST）过程可以识别软件中的安全漏洞。
在软件投入运行之前，应评估以下内容：
??a）攻击面和最小特权原则；
??b）对最常见的编程错误进行分析，并记录这些错误已得到缓解。
审查和维护
代码投入运行后：
??a）其更新应该被安全地打包和部署；
??b）报告的信息安全漏洞应得到处理（参见8.8）；
??c）应记录错误和可疑攻击，并定期审查日志，以便在必要时对代码进行调整；
??d）应保护源代码免受未经授权的访问和篡改（例如，通过使用配置管理工具，这些工具通常提供访问控制和版本控制等功能）。
如果使用外部工具和库，组织应该考虑：
??a）确保外部库得到管理（例如，通过维护所用库及其版本的清单）并随着发布周期定期更新；
??b）选择、授权和重用经过严格审查的组件，特别是身份鉴别和加密组件；
??c）外部组件的许可证、安全性和历史；
??d）确保软件是可维护的、可跟踪的，并且来自经过验证的、有信誉的来源；
??e）开发资源和产品的充分长期的可用性。
当软件包需要修改时，应考虑以下几点：
??a）内置控制和完整性流程受到损害的风险；
??b）是否获得厂商的同意；
??c）从供应商处获得所需变更作为标准程序更新的可能性；
??d）如果组织因变更而对软件的未来维护负责，会产生什么影响；
??e）与正在使用的其他软件的兼容性。
其他信息
一个指导原则是确保与安全相关的代码在必要时被调用，并且是其本身防篡改的。从编译的二进制代码安装的程序也应具有这些属性，但只针对应用程序中保存的数据。对于解释语言，只有当代码在用户和使用它的进程不可访问的服务器上执行，并且其数据保存在类似的受保护数据库中时，这个概念才起作用。例如，解释型代码可以在云服务上运行，其中对代码本身的访问需要管理员权限。这种管理员访问应该受到安全机制的保护，例如即时管理原则和强身份验证。如果应用程序所有者可以通过直接远程访问服务器来访问脚本，那么原则上攻击者也可以。在这种情况下，应该配置web服务器阻止目录浏览。
应用程序代码的最佳设计是基于这样的假设，即它总是会由于错误或恶意行为而受到攻击。此外，关键应用程序应设计为容忍内部故障。例如，在将数据用于人身安全或财务关键应用等应用程序之前，应检查复杂算法的输出，以确保其位于安全范围内。执行边界检查的代码很简单，因此更容易证明正确性。
一些web应用程序容易受到各种由糟糕的设计和编码引入的漏洞的影响，例如数据库注入和跨站点脚本攻击。在这些攻击中，可以操纵请求来滥用web服务器功能。
关于信通技术安全评估的更多信息，可查阅ISO/IEC 15408系列。
8.29 开发和验收中的安全性测试
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #识别 | #应用安全 #信息安全 #系统和网络安全 | #保护 |
控制
应该在开发生命周期中定义和实现安全测试过程。
目的
在将应用程序或代码部署到生产环境之前，验证其是否满足信息安全要求。
指南
在开发过程中，应对新的信息系统、升级和新版本进行彻底的测试和验证。安全测试应该是系统或组件测试不可或缺的一部分。
安全测试应该根据一组需求进行，这些需求可以表示为功能性的或者非功能性的。安全测试应包括以下测试：
??a）安全功能 [如用户认证（参见8.5）、访问限制（参见8.3）和使用加密技术（参见8.24）] ；
??b）安全编码（参见8.28）；
??c）安全配置（参见8.9、8.20和8.22），包括操作系统、防火墙和其他安全组件的安全配置。
应该使用一套标准来确定测试计划。测试的范围应该与系统的重要性、性质以及引入的变更的潜在影响相称。测试计划应包括：
??a）活动和测试的详细时间表；
??b）在一系列条件下的投入和预期产出；
??c）评估结果的标准；
??d）决定必要的进一步行动。
组织可以利用自动化工具，如代码分析工具或漏洞扫描器，并应验证安全相关缺陷的补救措施。
对于内部开发，这样的测试最初应该由开发团队执行。然后应进行独立的验收测试，以确保系统按预期运行，并且仅按预期运行（参见5.8）。应考虑以下几点：
??a）作为测试安全缺陷的相关元素，执行代码评审活动，包括非预期的输入和条件；
??b）执行漏洞扫描以识别不安全的配置和系统漏洞；
??c）执行渗透测试以识别不安全的代码和设计。
对于外包开发和采购组件，应遵循采购流程。与供应商的合同应响应已确定的安全要求（参见5.20）。在采购之前，产品和服务应根据这些标准进行评估。
测试应在与目标生产环境尽可能匹配的测试环境中进行，以确保系统不会给组织的环境带来漏洞，并且测试是可靠的（参见8.31）。
其他信息
可以建立多个测试环境，用于不同类型的测试（例如功能和性能测试）。这些不同的环境可以是虚拟的，通过单独的配置来模拟各种操作环境。
还需要考虑测试环境、工具和技术的测试和监控，以确保有效的测试。同样的考虑也适用于对开发、测试和生产环境中部署的监控系统的监控。需要根据系统和数据的敏感性做出判断，以确定多少层的自身测试（meta-testing，也作元测试）是有效的。
译者注：meta-testing大概是这个意思：验证你用于保障的方法是有保障的，以及你用于保障保障方法有保障的方法是有保障的~~然后酌情决定套娃套几层~~
8.30 外包开发
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 #检测性 | #保密性 #完整性 #可用性 | #识别 #保护 #检测 | #系统和网络安全 #应用安全 #供应商关系安全 | #治理与生态系统 #保护 |
控制
组织应指导、监控和审查与外包系统开发相关的活动。
目的
确保在外包系统开发中实施组织要求的信息安全措施。
指南
在外包系统开发的情况下，组织应该就需求和期望进行沟通并达成一致，并持续监控和审查外包工作的交付是否满足这些期望。在组织的整个外部供应链中，应考虑以下几点：
??a）与外包内容相关的许可协议、代码所有权和知识产权（参见5.32）；
??b）安全设计、编码和测试实践的合同要求（参见8.25至8.29）；
??c）外包方开发人员提供威胁模型以供斟酌；
??d）对可交付物的质量和准确性的验收测试（参见8.29）；
??e）提供证据证明建立了最低可接受水平的安全和隐私能力（如保证报告）。
??f）提供证据证明已经进行了充分的测试，以防止在交付时出现恶意内容（有意和无意）；
??g）提供证据证明已经进行了足够的测试来防范已知漏洞的存在；
??h）软件源代码的托管协议（例如，如果供应商停业）；
??i）审计开发流程和控制的合同权利；
??j）开发环境的安全要求（参见8.31）；
??k）考虑适用的法律（如保护个人数据）。
其他信息
关于供应商关系的更多信息可以在ISO/IEC 27036系列中找到。
8.31 开发、测试和生产环境的分离
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
控制
开发、测试和生产环境应该分离并分别保护。
目的
保护生产环境和数据免受开发和测试活动的危害。
指南
为防止影响生产，应该识别和实现生产、测试和开发环境之间的隔离级别。
应考虑以下事项：
??a）充分分离开发和生产系统，并在不同的域中运行它们（例如，在单独的虚拟或物理环境中）；
??b）定义、记录和实施从开发到生产状态的软件部署规则和授权；
??c）在应用到生产系统之前，在测试或试运行环境中测试对生产系统和应用程序的变更（参见8.29）；
??d）不在生产环境中测试，已定义并获批准的例外情况除外；
??e）非必要情况下，不得从生产系统访问编译器、编辑器和其他开发工具或实用程序；
??f）在菜单中显示适当的环境识别标签，以减少出错的风险；
??g）不要将敏感信息复制到开发和测试系统环境中，除非为开发和测试系统提供了等效的控制措施。
在所有情况下，都应该保护开发和测试环境，顾及：
??a）修补和更新所有开发、集成和测试工具（包括构建器、集成器、编译器、配置系统和库）；
??b）系统和软件的安全配置；
??c）控制对环境的访问；
??d）监控环境和存储在其中的代码的变化；
??e）环境的安全监控；
??f）备份环境。
未经事先审查和批准，单个个人不应既能对开发环境又能对生产环境进行更改。这可以通过分离访问权限或通过受监控的规则来实现。在异常情况下，应实施详细的日志记录和实时监控等额外措施，以便检测未经授权的更改并采取相应措施。
其他信息
如果没有足够的措施和程序，有权访问生产系统的开发人员和测试人员可能会带来重大风险（例如，对文件或系统环境进行不必要的修改、系统故障、在生产系统中运行未经授权和未经测试的代码、泄露机密数据、数据完整性和可用性问题）。需要维护一个已确知的且稳定的环境来执行有意义的测试，并防止开发人员不适当地访问生产环境。
措施和程序包括精心设计的角色，以及实施职责分离要求和适当的监控流程。
开发和测试人员也对生产信息的保密性构成威胁。如果开发和测试活动共享相同的计算环境，它们可能会导致软件或信息的意外更改。因此，最好将开发、测试和生产环境分开，以降低意外变更或未经授权访问生产软件和业务数据的风险（参见8.33测试信息保护）。
在某些情况下，可以故意模糊开发、测试和生产环境之间的区别，可以在开发环境中进行测试，或者受控地部署到实时用户或服务器环境（例如，少量试点用户）。在某些情况下，产品测试可以通过在组织内部实际使用产品来进行。此外，为了减少实时部署的停机时间，可以支持两个完全相同的生产环境，在这两个环境中，任何时刻都只有一个是活跃的。
在开发和测试环境（8.33）中使用生产数据的支持过程是必要的。
组织在进行最终用户培训时，也可以考虑本节中针对培训环境提供的指导。
8.32 变更管理
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
控制
信息处理设施和信息系统的变更应遵循变更管理程序。
目的
在执行变更时保护信息安全。
指南
新系统的引入和现有系统的重大变更应遵循一致同意的规则和正式的文档、规范、测试、质量控制和管理实施流程。管理职责和程序应到位，以确保所有变更得到适当的控制。
应记录并执行变更控制程序，以确保从早期设计阶段到所有后续维护工作的整个系统开发生命周期中，信息处理设施和信息系统中信息的机密性、完整性和可用性。
只要可行，就应整合ICT基础设施和软件的变更控制程序。
变更控制程序应包括：
??a）考虑所有依赖因素，规划和评估变更的潜在影响；
??b）变更授权；
??c）向相关利益方传达变更；
??d）变更测试和测试验收（参见8.29）；
??e）实施变更，包括部署计划；
??f）考虑紧急情况和意外情况，包括回退程序；
??g）维护包括上述所有内容的变更记录；
??h）确保操作文件（参见5.37）和用户程序根据需要进行更改，以保持适用；
??i）确保ICT连续性计划以及响应和恢复程序（参见5.30）在必要时进行更改，以保持适用。
其他信息
对信息处理设施和信息系统的变更控制不足是系统或安全故障的常见原因。生产环境的变化，尤其是将软件从开发环境转移到操作环境时，会影响应用程序的完整性和可用性。
改变软件会影响生产环境，反之亦然。
良好实践包括在与生产和开发环境隔离的环境中测试ICT组件（参见8.31）。这提供了一种控制新软件的方法，并允许对用于测试目的的操作信息进行额外保护。这应该包括补丁、服务包和其他更新。
生产环境包括操作系统、数据库和中间件平台。控制应适用于应用程序和基础设施的变更。
8.33 测试信息
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 | #保护 | #信息保护 | #保护 |
控制
应适当选择、保护和管理测试信息。
目的
确保测试的相关性和测试中使用的运营信息的保护。
指南
应选择测试信息，以确保测试结果的可靠性和相关操作信息的保密性。敏感信息（包括个人身份信息）不应复制到开发和测试环境中（参见8.31）。
当用于测试目的时，无论测试环境是在内部构建还是基于云服务构建，都应遵循以下准则来保护运营信息的副本：
??a）对测试环境应用的访问控制程序与运营环境一致；
??b）每次运营信息被复制到测试环境时具有单独的授权；
??c）记录运营信息的复制和使用，以提供审计跟踪；
??d）如果用于测试，通过移除或遮盖（参见8.11）来保护敏感信息；
??e）测试完成后，立即从测试环境中正确删除（参见8.10）操作信息，以防止未经授权使用测试信息。
测试信息应安全存储（防止篡改，否则会导致无效结果）并仅用于测试目的。
其他信息
系统和验收测试可能需要大量的、尽可能接近操作信息的测试信息。
8.34 审计测试期间信息系统的保护
| 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|
| #预防性 | #保密性 #完整性 #可用性 | #保护 | #系统和网络安全 #信息保护 | #治理与生态系统 #保护 |
控制
涉及操作系统评估的审计测试和其他保证活动应在测试人员和适当的管理人员之间进行规划和协商。
目的
尽量减少审计和其他保证活动对运营系统和业务的影响流程。
指南
应遵守以下准则：
??a）与适当的管理层就访问系统和数据的审计请求达成一致；
??b）同意并控制技术审计测试的范围；
??c）将审计测试限制为对软件和数据的只读访问。如果只读访问不可用于获得必要的信息，则由有经验的管理员代表审计员执行测试，该管理员具有必要的访问权限；
??d）如果允许访问，则在允许访问之前，确定并验证用于访问系统的设备（如笔记本电脑或平板电脑）的安全要求（如防病毒和修补）；
??e）如需进行非只读的访问，则仅允许对系统文件的独立副本进行，在审计完成时删除它们。如果有义务根据审计文件要求保存这些文件，则给予它们适当的保护；
??f）识别并审批特殊或附加处理的请求，如运行审计工具；
??g）在工作时间之外运行可能影响系统可用性的审计测试；
??h）出于审计和测试目的，监控和记录所有访问。
其他信息
审计测试和其他保证活动也可以发生在开发和测试系统上，这种测试可能影响代码的完整性或者导致在这种环境中保存的任何敏感信息的泄露。
附录A 使用属性
（资料性附录）
A.1 概述
本附录提供了一个表格来演示如何使用属性来创建控制的不同视图。属性的五个例子是（参见4.2）：
??a）控制类型（#预防型、#检测型和#纠正型）
??b）信息安全特性（#机密性、#完整性和#可用性）
??c）网络安全概念（#识别、#保护、#检测、#响应、#恢复）
??d）运营能力（#治理、#资产管理、#信息保护、#人力资源安全、#物理安全、#系统和网络安全、#应用安全、#安全配置、#身份和访问管理、#威胁和漏洞管理、#连续性、#供应商关系安全、#法律和合规性、#信息安全事件管理、#信息安全保证）
??e）安全域（#治理与生态系统、#保护、#防御、#韧性）
表A.1包含本文件中所有控制措施及其给定属性值的矩阵。
可使用简单的电子表格或数据库等工具对矩阵进行过滤或排序，其中可包含更多信息，如控制文本、指南、组织特定指南或属性（参见A.2）。
| ISO/IEC 27002:2022 控制序号 | 控制名称 | 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|---|---|
| 5.1 | 信息安全策略 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #治理 | #治理与生态系统 #韧性 |
| 5.2 | 信息安全角色和职责 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #治理 | #治理与生态系统 #保护 #韧性 |
| 5.3 | 职责分离 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #治理 #身份和访问管理 | #治理与生态系统 |
| 5.4 | 管理层责任 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #治理 | #治理与生态系统 |
| 5.5 | 与职能机构的联系 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #保护 #响应 #恢复 | #治理 | #防御 #韧性 |
| 5.6 | 与特定相关方的联系 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 #恢复 | #治理 | #防御 |
| 5.7 | 威胁情报 | #预防性 #检测性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #检测 #响应 | #威胁和漏洞能力管理 | #防御 #韧性 |
| 5.8 | 项目管理中的信息安全 | #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #治理 | #治理与生态系统 #保护 |
| 5.9 | 信息和其他相关资产的清单 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #资产管理 | #治理与生态系统 #保护 |
| 5.10 | 信息和其他相关资产的可接受的使用 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 #信息保护 | #治理与生态系统 #保护 |
| 5.11 | 资产返还 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 | #保护 |
| 5.12 | 信息分类 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #信息保护 | #保护 #防御 |
| 5.13 | 信息标签 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #信息保护 | #保护 #防御 |
| 5.14 | 信息传递 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 #信息保护 | #保护 |
| 5.15 | 访问控制 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
| 5.16 | 身份管理 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
| 5.17 | 鉴别信息 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
| 5.18 | 访问权限 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
| 5.19 | 供应商关系中的信息安全 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #供应商关系安全 | #治理与生态系统 #保护 |
| 5.20 | 解决供应商协议中的信息安全问题 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #供应商关系安全 | #治理与生态系统 #保护 |
| 5.21 | 管理ICT供应链中的信息安全 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #供应商关系安全 | #治理与生态系统 #保护 |
| 5.22 | 供应商服务的监控、审查和变更管理 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #供应商关系安全 #信息安全保证 | #治理与生态系统 #保护 #防御 |
| 5.23 | 使用云服务的信息安全 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #供应商关系安全 | #治理与生态系统 #保护 |
| 5.24 | 规划和准备管理信息安全事故 | #纠正性 | #保密性 #完整性 #可用性 | #响应 #恢复 | #治理 #信息安全事件管理 | #防御 |
| 5.25 | 信息安全事件的评估和决策 | #检测性 | #保密性 #完整性 #可用性 | #检测 #响应 | #信息安全事件管理 | #防御 |
| 5.26 | 应对信息安全事故 | #纠正性 | #保密性 #完整性 #可用性 | #响应 #恢复 | #信息安全事件管理 | #防御 |
| 5.27 | 从信息安全事故中吸取教训 | #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #信息安全事件管理 | #防御 |
| 5.28 | 收集证据 | #纠正性 | #保密性 #完整性 #可用性 | #检测 #响应 | #信息安全事件管理 | #防御 |
| 5.29 | 中断期间的信息安全 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 | #连续性 | #保护 #韧性 |
| 5.30 | ICT为业务连续性做好准备 | #纠正性 | #可用性 | #响应 | #连续性 | #韧性 |
| 5.31 | 法律、法规、监管和合同要求 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #法律与合规性 | #治理与生态系统 #保护 |
| 5.32 | 知识产权 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #法律与合规性 | #治理与生态系统 |
| 5.33 | 记录保护 | #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #法律与合规性 #资产管理 #信息保护 | #防御 |
| 5.34 | PII隐私和保护 | #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #信息保护 #法律与合规性 | #保护 |
| 5.35 | 信息安全独立审查 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #保护 | #信息安全保证 | #治理与生态系统 |
| 5.36 | 信息安全策略、规则和标准的遵从性 | #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #法律与合规性 #信息安全保证 | #治理与生态系统 |
| 5.37 | 文件化的操作程序 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #恢复 | #资产管理 #物理安全 #系统和网络安全 #应用安全 #安全配置 #身份和访问管理 #威胁和漏洞管理 #连续性 #信息安全事件管理 | #治理与生态系统 #保护 #防御 |
| 6.1 | 筛选 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 | #治理与生态系统 |
| 6.2 | 雇佣条款和条件 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 | #治理与生态系统 |
| 6.3 | 信息安全意识、教育和培训 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 | #治理与生态系统 |
| 6.4 | 纪律程序 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 | #人力资源安全 | #治理与生态系统 |
| 6.5 | 雇佣关系终止或变更后的责任 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #人力资源安全 #资产管理 | #治理与生态系统 |
| 6.6 | 保密或不披露协议 | #预防性 | #保密性 | #保护 | #人力资源安全 #信息保护 #供应商关系 | #治理与生态系统 |
| 6.7 | 远程工作 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 #信息保护 #物理安全 #系统和网络安全 | #保护 |
| 6.8 | 报告信息安全事件 | #检测性 | #保密性 #完整性 #可用性 | #检测 | #信息安全事件管理 | #防御 |
| 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.1 | 用户终端设备 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #资产管理 #信息保护 | #保护 |
| 8.2 | 特殊访问权 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
| 8.3 | 信息访问约束 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
| 8.4 | 获取源代码 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 #应用安全 #安全配置 | #保护 |
| 8.5 | 安全身份认证 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #身份和访问管理 | #保护 |
| 8.6 | 容量管理 | #预防性 #检测性 | #完整性 #可用性 | #识别 #保护 #检测 | #连续性 | #治理与生态系统 #保护 |
| 8.7 | 防范恶意软件 | #预防性 #检测性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #检测 | #系统和网络安全 #信息保护 | #保护 #防御 |
| 8.8 | 技术漏洞的管理 | #预防性 | #保密性 #完整性 #可用性 | #识别 #保护 | #威胁和漏洞管理 | #治理和生态系统 #保护 #防御 |
| 8.9 | 配置管理 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #安全配置 | #保护 |
| 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.23 | web过滤 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #系统和网络安全 | #保护 |
| 8.24 | 密码学的使用 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #安全配置 | #保护 |
| 8.25 | 安全开发生命周期 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
| 8.26 | 应用程序安全要求 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 #防御 |
| 8.27 | 安全系统架构和工程原理 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
| 8.28 | 安全编码 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
| 8.29 | 开发和验收中的安全性测试 | #预防性 | #保密性 #完整性 #可用性 | #识别 | #应用安全 #信息安全 #系统和网络安全 | #保护 |
| 8.30 | 外包开发 | #预防性 #检测性 | #保密性 #完整性 #可用性 | #识别 #保护 #检测 | #系统和网络安全 #应用安全 #供应商关系安全 | #治理与生态系统 #保护 |
| 8.31 | 开发、测试和生产环境的分离 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
| 8.32 | 变更管理 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #应用安全 #系统和网络安全 | #保护 |
| 8.33 | 测试信息 | #预防性 | #保密性 #完整性 | #保护 | #信息保护 | #保护 |
| 8.34 | 审计测试期间信息系统的保护 | #预防性 | #保密性 #完整性 #可用性 | #保护 | #系统和网络安全 #信息保护 | #治理与生态系统 #保护 |
表A.2显示了一个如何通过特定属性值过滤来创建视图的例子，在这个例子中是#Corrective。
| ISO/IEC 27002:2022 控制序号 | 控制名称 | 控制类型 | 信息安全特性 | 网络安全概念 | 运营能力 | 安全域 |
|---|---|---|---|---|---|---|
| 5.5 | 与职能机构的联系 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #保护 #响应 #恢复 | #治理 | #防御 #韧性 |
| 5.6 | 与特定相关方的联系 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 #恢复 | #治理 | #防御 |
| 5.7 | 威胁情报 | #预防性 #检测性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #检测 #响应 | #威胁和漏洞能力管理 | #防御 #韧性 |
| 5.24 | 规划和准备管理信息安全事故 | #纠正性 | #保密性 #完整性 #可用性 | #响应 #恢复 | #治理 #信息安全事件管理 | #防御 |
| 5.26 | 应对信息安全事故 | #纠正性 | #保密性 #完整性 #可用性 | #响应 #恢复 | #信息安全事件管理 | #防御 |
| 5.28 | 收集证据 | #纠正性 | #保密性 #完整性 #可用性 | #检测 #响应 | #信息安全事件管理 | #防御 |
| 5.29 | 中断期间的信息安全 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 | #连续性 | #保护 #韧性 |
| 5.30 | ICT为业务连续性做好准备 | #纠正性 | #可用性 | #响应 | #连续性 | #韧性 |
| 5.35 | 信息安全独立审查 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #识别 #保护 | #信息安全保证 | #治理与生态系统 |
| 5.37 | 文件化的操作程序 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #恢复 | #资产管理 #物理安全 #系统和网络安全 #应用安全 #安全配置 #身份和访问管理 #威胁和漏洞管理 #连续性 #信息安全事件管理 | #治理与生态系统 #保护 #防御 |
| 6.4 | 纪律程序 | #预防性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #响应 | #人力资源安全 | #治理与生态系统 |
| 8.7 | 防范恶意软件 | #预防性 #检测性 #纠正性 | #保密性 #完整性 #可用性 | #保护 #检测 | #系统和网络安全 #信息保护 | #保护 #防御 |
| 8.13 | 信息备份 | #纠正性 | #完整性 #可用性 | #恢复 | #连续性 | #保护 |
| 8.16 | 活动监测 | #检测性 #纠正性 | #保密性 #完整性 #可用性 | #检测 #响应 | #信息安全事件管理 | #防御 |
A.2 组织视图
由于属性用于创建不同的控制视图，组织可以放弃本文档中建议的属性示例，并创建自己的具有不同值的属性，以满足组织中的特定需求。此外，分配给每个属性的值可能因组织而异，因为组织可能对控制或与属性关联的值的用途或适用性有不同的看法（当值特定于组织的上下文时）。第一步是理解为什么组织特有的属性是可取的。例如，如果一个组织已经基于事件构建了其风险处理计划 [参见ISO/IEC 27001：2013，6.1.3 e）] ，它可能希望将风险情景属性与本文档中的每个控制相关联。
这种属性的优点是加快完成与风险处理相关的ISO/IEC 27001要求的过程，即将通过风险处理过程确定的控制措施（称为“必要”控制措施）与ISO/IEC 27001：2013附录A中的控制措施（在本文件中发布）进行比较，以确保没有必要的控制措施被忽略。
一旦知道了目的和优点，下一步就是确定属性值。例如，组织可能确定9个事件：
??1）移动设备丢失或被盗；
??2）组织场所的丢失或被盗；
??3）不可抗力、故意破坏和恐怖主义；
??4）软件、硬件、电源、互联网和通信故障；
??5）诈骗；
??6）黑客攻击；
??7）披露；
??8）违反法律；
??9）社会工程。
因此，第二步可以给每个事件分配标识符（例如，E1，E2，…，E9）。
第三步是将控制标识符和控制名称从该文档复制到电子表格或数据库中，并将属性值与每个控制相关联，记住每个控制可以有多个属性值。
最后一步是对电子表格进行排序或查询数据库以提取所需的信息。组织属性（和可能的值）的其他示例包括：
??a）成熟度（来自ISO/IEC 33000系列或其他成熟度模型的值）；
??b）实施状态（待做、进行中、部分实施、完全实施）；
??c）优先级（1、2、3等）；
??d）涉及的组织领域（安全、信息和通信技术、人力资源、高层管理等）；
??e）事件；
??f）涉及的资产；
??g）构建和运行，以区分在服务生命周期的不同步骤中使用的控制；
??h）组织使用的或可以转换的其他框架。
附录B ISO/IEC 27002:2022(本文件)与ISO/IEC 27002:2013的对照
（资料性附录）
本附录的目的是为目前使用ISO/IEC
27002:2013标准并希望过渡到该版本的组织提供向后兼容性。
表B.1提供了第5章至第8章中详述的控制措施与ISO/IEC 27002:2013的对照。
| ISO/IEC 27002:2022 控制序号 | ISO/IEC 27002:2013控制序号 | 控制名称 |
|---|---|---|
| 5.1 | 5.1.1, 5.1.2 | 信息安全策略 |
| 5.2 | 6.1.1 | 信息安全角色和职责 |
| 5.3 | 6.1.2 | 职责分离 |
| 5.4 | 7.2.1 | 管理层责任 |
| 5.5 | 6.1.3 | 与职能机构的联系 |
| 5.6 | 6.1.4 | 与特定相关方的联系 |
| 5.7 | 新的 | 威胁情报 |
| 5.8 | 6.1.5, 14.1.1 | 项目管理中的信息安全 |
| 5.9 | 8.1.1, 8.1.2 | 信息和其他相关资产的清单 |
| 5.10 | 8.1.3, 8.2.3 | 信息和其他相关资产的可接受的使用 |
| 5.11 | 8.1.4 | 资产返还 |
| 5.12 | 8.2.1 | 信息分类 |
| 5.13 | 8.2.2 | 信息标签 |
| 5.14 | 13.2.1, 13.2.2,13.2.3 | 信息传递 |
| 5.15 | 9.1.1, 9.1.2 | 访问控制 |
| 5.16 | 9.2.1 | 身份管理 |
| 5.17 | 9.2.4, 9.3.1,9.4.3 | 鉴别信息 |
| 5.18 | 9.2.2, 9.2.5,9.2.6 | 访问权限 |
| 5.19 | 15.1.1 | 供应商关系中的信息安全 |
| 5.20 | 15.1.2 | 解决供应商协议中的信息安全问题 |
| 5.21 | 15.1.3 | 管理ICT供应链中的信息安全 |
| 5.22 | 15.2.1, 15.2.2 | 供应商服务的监控、审查和变更管理 |
| 5.23 | 新的 | 使用云服务的信息安全 |
| 5.24 | 16.1.1 | 规划和准备管理信息安全事故 |
| 5.25 | 16.1.4 | 信息安全事件的评估和决策 |
| 5.26 | 16.1.5 | 应对信息安全事故 |
| 5.27 | 16.1.6 | 从信息安全事故中吸取教训 |
| 5.28 | 16.1.7 | 收集证据 |
| 5.29 | 17.1.1, 17.1.2, 17.1.3 | 中断期间的信息安全 |
| 5.30 | 新的 | ICT为业务连续性做好准备 |
| 5.31 | 18.1.1, 18.1.5 | 法律、法规、监管和合同要求 |
| 5.32 | 18.1.2 | 知识产权 |
| 5.33 | 18.1.3 | 记录保护 |
| 5.34 | 18.1.4 | PII隐私和保护 |
| 5.35 | 18.2.1 | 信息安全独立审查 |
| 5.36 | 18.2.2, 18.2.3 | 信息安全策略、规则和标准的遵从性 |
| 5.37 | 12.1.1 | 文件化的操作程序 |
| 6.1 | 7.1.1 | 筛选 |
| 6.2 | 7.1.2 | 雇佣条款和条件 |
| 6.3 | 7.2.2 | 信息安全意识、教育和培训 |
| 6.4 | 7.2.3 | 纪律程序 |
| 6.5 | 7.3.1 | 雇佣关系终止或变更后的责任 |
| 6.6 | 13.2.4 | 保密或不披露协议 |
| 6.7 | 6.2.2 | 远程工作 |
| 6.8 | 16.1.2, 16.1.3 | 报告信息安全事件 |
| 7.1 | 11.1.1 | 物理安全周界 |
| 7.2 | 11.1.2, 11.1.6 | 物理入口 |
| 7.3 | 11.1.3 | 保护办公室、房间和设施 |
| 7.4 | 新的 | 物理安全监控 |
| 7.5 | 11.1.4 | 抵御物理和环境威胁 |
| 7.6 | 11.1.5 | 在安全区域工作 |
| 7.7 | 11.2.9 | 桌面清理和屏幕清理 |
| 7.8 | 11.2.1 | 设备安置和保护 |
| 7.9 | 11.2.6 | 场外资产的安全 |
| 7.10 | 8.3.1, 8.3.2, 8.3.3, 11.2.5 | 存储介质 |
| 7.11 | 11.2.2 | 支持性设施 |
| 7.12 | 11.2.3 | 布线安全 |
| 7.13 | 11.2.4 | 设备维护 |
| 7.14 | 11.2.7 | 设备的安全作废或再利用 |
| 8.1 | 6.2.1, 11.2.8 | 用户终端设备 |
| 8.2 | 9.2.3 | 特殊访问权 |
| 8.3 | 9.4.1 | 信息访问约束 |
| 8.4 | 9.4.5 | 获取源代码 |
| 8.5 | 9.4.2 | 安全身份认证 |
| 8.6 | 12.1.3 | 容量管理 |
| 8.7 | 12.2.1 | 防范恶意软件 |
| 8.8 | 12.6.1, 18.2.3 | 技术漏洞的管理 |
| 8.9 | 新的 | 配置管理 |
| 8.10 | 新的 | 信息删除 |
| 8.11 | 新的 | 数据遮盖 |
| 8.12 | 新的 | 防止数据泄漏 |
| 8.13 | 12.3.1 | 信息备份 |
| 8.14 | 17.2.1 | 信息处理设备的冗余 |
| 8.15 | 12.4.1, 12.4.2, 12.4.3 | 日志 |
| 8.16 | 新的 | 活动监测 |
| 8.17 | 12.4.4 | 时钟同步 |
| 8.18 | 9.4.4 | 特权实用程序的使用 |
| 8.19 | 12.5.1, 12.6.2 | 在操作系统上安装软件 |
| 8.20 | 13.1.1 | 网络安全 |
| 8.21 | 13.1.2 | 网络服务的安全性 |
| 8.22 | 13.1.3 | 网络隔离 |
| 8.23 | 新的 | web过滤 |
| 8.24 | 10.1.1, 10.1.2 | 密码学的使用 |
| 8.25 | 14.2.1 | 安全开发生命周期 |
| 8.26 | 14.1.2, 14.1.3 | 应用程序安全要求 |
| 8.27 | 14.2.5 | 安全系统架构和工程原理 |
| 8.28 | 新的 | 安全编码 |
| 8.29 | 14.2.8, 14.2.9 | 开发和验收中的安全性测试 |
| 8.30 | 14.2.7 | 外包开发 |
| 8.31 | 12.1.4, 14.2.6 | 开发、测试和生产环境的分离 |
| 8.32 | 12.1.2, 14.2.2, 14.2.3, 14.2.4 | 变更管理 |
| 8.33 | 14.3.1 | 测试信息 |
| 8.34 | 12.7.1 | 审计测试期间信息系统的保护 |
| ISO/IEC 27002:2013 控制序号 | ISO/IEC 27002:2022 控制序号 | 符合ISO/IEC 27002:2013的控制名称 |
|---|---|---|
| 5 | 信息安全策略 | |
| 5.1 | 信息安全管理指导 | |
| 5.1.1 | 5.1 | 信息安全策略 |
| 5.1.2 | 5.1 | 信息安全策略的评审 |
| 6 | 信息安全组织 | |
| 6.1 | 内部组织 | |
| 6.1.1 | 5.2 | 信息安全的角色和责任 |
| 6.1.2 | 5.3 | 职责分离 |
| 6.1.3 | 5.5 | 与职能机构的联系 |
| 6.1.4 | 5.6 | 与特定相关方的联系 |
| 6.1.5 | 5.8 | 项目管理中的信息安全 |
| 6.2 | 移动设备和远程工作 | |
| 6.2.1 | 8.1 | 移动设备策略 |
| 6.2.2 | 6.7 | 远程工作 |
| 7 | 人力资源安全 | |
| 7.1 | 任用前 | |
| 7.1.1 | 6.1 | 审查 |
| 7.1.2 | 6.2 | 任用条款及条件 |
| 7.2 | 任用中 | |
| 7.2.1 | 5.4 | 管理责任 |
| 7.2.2 | 6.3 | 信息安全意识、教育和培训 |
| 7.2.3 | 6.4 | 违规处理过程 |
| 7.3 | 任用的终止和变更 | |
| 7.3.1 | 6.5 | 任用终止或变更的责任 |
| 8 | 资产管理 | |
| 8.1 | 有关资产的责任 | |
| 8.1.1 | 5.9 | 资产清单 |
| 8.1.2 | 5.9 | 资产的所属关系 |
| 8.1.3 | 5.1 | 资产的可接受使用 |
| 8.1.4 | 5.11 | 资产归还 |
| 8.2 | 信息分级 | |
| 8.2.1 | 5.12 | 信息的分级 |
| 8.2.2 | 5.13 | 信息的标记 |
| 8.2.3 | 5.1 | 资产的处理 |
| 8.3 | 介质处理 | |
| 8.3.1 | 7.1 | 移动介质的管理 |
| 8.3.2 | 7.1 | 介质的处置 |
| 8.3.3 | 7.1 | 物理介质的转移 |
| 9 | 访问控制 | |
| 9.1 | 访问控制的业务要求 | |
| 9.1.1 | 5.15 | 访问控制策略 |
| 9.1.2 | 5.15 | 网络和网络服务的访问 |
| 9.2 | 用户访问管理 | |
| 9.2.1 | 5.16 | 用户注册和注销 |
| 9.2.2 | 5.18 | 用户访问供给 |
| 9.2.3 | 8.2 | 特许访问权管理 |
| 9.2.4 | 5.17 | 用户的秘密鉴别信息管理 |
| 9.2.5 | 5.18 | 用户访问权的评审 |
| 9.2.6 | 5.18 | 访问权的移除或调整 |
| 9.3 | 用户责任 | |
| 9.3.1 | 5.17 | 秘密鉴别信息的使用 |
| 9.4 | 系统和应用访问控制 | |
| 9.4.1 | 8.3 | 信息访问限制 |
| 9.4.2 | 8.5 | 安全登录规程 |
| 9.4.3 | 5.17 | 口令管理系统 |
| 9.4.4 | 8.18 | 特权实用程序的使用 |
| 9.4.5 | 8.4 | 程序源代码的访问控制 |
| 10 | 密码 | |
| 10.1 | 密码控制 | |
| 10.1.1 | 8.24 | 密码控制的使用策略 |
| 10.1.2 | 8.24 | 密钥管理 |
| 11 | 物理和环境安全 | |
| 11.1 | 安全区域 | |
| 11.1.1 | 7.1 | 物理安全边界 |
| 11.1.2 | 7.2 | 物理入口控制 |
| 11.1.3 | 7.3 | 办公室、房间和设施的安全保护 |
| 11.1.4 | 7.5 | 外部和环境威胁的安全防护 |
| 11.1.5 | 7.6 | 在安全区域工作 |
| 11.1.6 | 7.2 | 交接区 |
| 11.2 | 设备 | |
| 11.2.1 | 7.8 | 设备安置和保护 |
| 11.2.2 | 7.11 | 支持性设施 |
| 11.2.3 | 7.12 | 布缆安全 |
| 11.2.4 | 7.13 | 设备维护 |
| 11.2.5 | 7.1 | 资产的移动 |
| 11.2.6 | 7.9 | 组织场所外的设备与资产安全 |
| 11.2.7 | 7.14 | 设备的安全处置或再利用 |
| 11.2.8 | 8.1 | 无人值守的用户设备 |
| 11.2.9 | 7.7 | 清理桌面和屏幕策略 |
| 12 | 运行安全 | |
| 12.1 | 运行规程和责任 | |
| 12.1.1 | 5.37 | 文件化的操作规程 |
| 12.1.2 | 8.32 | 变更管理 |
| 12.1.3 | 8.6 | 容量管理 |
| 12.1.4 | 8.31 | 开发、测试和运行环境的分离 |
| 12.2 | 恶意软件防范 | |
| 12.2.1 | 8.7 | 恶意软件的控制 |
| 12.3 | 备份 | |
| 12.3.1 | 8.13 | 信息备份 |
| 12.4 | 日志和监视 | |
| 12.4.1 | 8.15 | 事态日志 |
| 12.4.2 | 8.15 | 日志信息的保护 |
| 12.4.3 | 8.15 | 管理员和操作员日志 |
| 12.4.4 | 8.17 | 时钟同步 |
| 12.5 | 运行软件控制 | |
| 12.5.1 | 8.19 | 运行系统软件的安装 |
| 12.6 | 技术方面的脆弱性管理 | |
| 12.6.1 | 8.8 | 技术方面脆弱性的管理 |
| 12.6.2 | 8.19 | 软件安装限制 |
| 12.7 | 信息系统审计的考虑 | |
| 12.7.1 | 8.34 | 信息系统审计控制 |
| 13 | 通信安全 | |
| 13.1 | 网络安全管理 | |
| 13.1.1 | 8.2 | 网络控制 |
| 13.1.2 | 8.21 | 网络服务的安全 |
| 13.1.3 | 8.22 | 网络中的隔离 |
| 13.2 | 信息传输 | |
| 13.2.1 | 5.14 | 信息传输策略和规程 |
| 13.2.2 | 5.14 | 信息传输协议 |
| 13.2.3 | 5.14 | 电子消息发送 |
| 13.2.4 | 6.6 | 保密或不泄露协议 |
| 14 | 系统获取、开发和维护 | |
| 14.1 | 信息系统的安全要求 | |
| 14.1.1 | 5.8 | 信息安全要求分析和说明 |
| 14.1.2 | 8.26 | 公共网络上应用服务的安全保护 |
| 14.1.3 | 8.26 | 应用服务事务的保护 |
| 14.2 | 开发和支持过程中的安全 | |
| 14.2.1 | 8.25 | 安全的开发策略 |
| 14.2.2 | 8.32 | 系统变更控制规程 |
| 14.2.3 | 8.32 | 运行平台变更后对应用的技术评审 |
| 14.2.4 | 8.32 | 软件包变更的限制 |
| 14.2.5 | 8.27 | 系统安全工程原则 |
| 14.2.6 | 8.31 | 安全的开发环境 |
| 14.2.7 | 8.3 | 外包开发 |
| 14.2.8 | 8.29 | 系统安全测试 |
| 14.2.9 | 8.29 | 系统验收测试 |
| 14.3 | 测试数据 | |
| 14.3.1 | 8.33 | 测试数据的保护 |
| 15 | 供应商关系 | |
| 15.1 | 供应商关系中的信息安全 | |
| 15.1.1 | 5.19 | 供应商关系的信息安全策略 |
| 15.1.2 | 5.2 | 在供应商协议中强调安全 |
| 15.1.3 | 5.21 | 信息与通信技术供应链 |
| 15.2 | 供应商服务交付管理 | |
| 15.2.1 | 5.22 | 供应商服务的监视和审查 |
| 15.2.2 | 5.22 | 供应商服务的变更管理 |
| 16 | 信息安全事件管理 | |
| 16.1 | 信息安全事件的管理和改进 | |
| 16.1.1 | 5.24 | 责任和规程 |
| 16.1.2 | 6.8 | 报告信息安全事态 |
| 16.1.3 | 6.8 | 报告信息安全弱点 |
| 16.1.4 | 5.25 | 信息安全事态的评估和决策 |
| 16.1.5 | 5.26 | 信息安全事件的响应 |
| 16.1.6 | 5.27 | 从信息安全事件中学习 |
| 16.1.7 | 5.28 | 证据的收集 |
| 17 | 业务连续性管理的信息安全方面 | |
| 17.1 | 信息安全的连续性 | |
| 17.1.1 | 5.29 | 规划信息安全连续性 |
| 17.1.2 | 5.29 | 实现信息安全连续性 |
| 17.1.3 | 5.29 | 验证、评审和评价信息安全连续性 |
| 17.2 | 冗余 | |
| 17.2.1 | 8.14 | 信息处理设施的可用性 |
| 18 | 符合性 | |
| 18.1 | 符合法律和合同要求 | |
| 18.1.1 | 5.31 | 适用的法律和合同要求的识别 |
| 18.1.2 | 5.32 | 知识产权 |
| 18.1.3 | 5.33 | 记录的保护 |
| 18.1.4 | 5.34 | 隐私和个人可识别信息保护 |
| 18.1.5 | 5.31 | 密码控制规则 |
| 18.2 | 信息安全评审 | |
| 18.2.1 | 5.35 | 信息安全的独立评审 |
| 18.2.2 | 5.36 | 符合安全策略和标准 |
| 18.2.3 | 5.36, 8.8 | 技术符合性评审 |
参考文献
[1] ISO 9000, Quality management systems — Fundamentals and vocabulary
[2] ISO 55001, Asset management — Management systems — Requirements
[3] ISO/IEC 11770 (all parts), Information security — Key management
[4] ISO/IEC 15408 (all parts), Information technology — Security techniques — Evaluation criteria for IT security
[5] ISO 15489 (all parts), Information and documentation — Records management
[6] ISO/IEC 17788, Information technology — Cloud computing — Overview and vocabulary
[7] ISO/IEC 17789, Information technology — Cloud computing — Reference architecture
[8] ISO/IEC 19086 (all parts), Cloud computing — Service level agreement (SLA) framework
[9] ISO/IEC 19770 (all parts), Information technology — IT asset management
[10] ISO/IEC 19941, Information technology — Cloud computing — Interoperability and portability
[11] ISO/IEC 20889, Privacy enhancing data de-identification terminology and classification of techniques
[12] ISO 21500, Project, programme and portfolio management — Context and concepts
[13] ISO 21502, Project, programme and portfolio management — Guidance on project management
[14] ISO 22301, Security and resilience — Business continuity management systems — Requirements
[15] ISO 22313, Security and resilience — Business continuity management systems — Guidance on the use of ISO 22301
[16] ISO/TS 22317, Societal security — Business continuity management systems — Guidelines for business impact analysis (BIA)
[17] ISO 22396, Security and resilience — Community resilience — Guidelines for information exchange between organizations
[18] ISO/IEC TS 23167, Information technology — Cloud computing — Common technologies and techniques
[19] ISO/IEC 23751:2022, Information technology — Cloud computing and distributed platforms — Data sharing agreement (DSA) framework
[20] ISO/IEC 24760 (all parts), IT Security and Privacy — A framework for identity management
[21] ISO/IEC 27001:2013, Information technology — Security techniques — Information security management systems — Requirements
[22] ISO/IEC 27005, Information technology — Security techniques — Information security risk management
[23] ISO/IEC 27007, Information security, cybersecurity and privacy protection — Guidelines for information security management systems auditing
[24] ISO/IEC TS 27008, Information technology — Security techniques — Guidelines for the assessment of information security controls
[25] ISO/IEC 27011, Information technology — Security techniques — Code of practice for Information security controls based on ISO/IEC 27002 for telecommunications organizations
[26] ISO/IEC TR 27016, Information technology — Security techniques — Information security management — Organizational economics
[27] ISO/IEC 27017, Information technology — Security techniques — Code of practice for information security controls based on ISO/IEC 27002 for cloud services
[28] ISO/IEC 27018, Information technology — Security techniques — Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors
[29] ISO/IEC 27019, Information technology — Security techniques — Information security controls for the energy utility industry
[30] ISO/IEC 27031, Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity
[31] ISO/IEC 27033 (all parts), Information technology — Security techniques — Network security
[32] ISO/IEC 27034 (all parts), Information technology — Application security
[33] ISO/IEC 27035 (all parts), Information technology — Security techniques — Information security incident management
[34] ISO/IEC 27036 (all parts), Information technology — Security techniques — Information security for supplier relationships
[35] ISO/IEC 27037, Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence
[36] ISO/IEC 27040, Information technology — Security techniques — Storage security
[37] ISO/IEC 27050 (all parts), Information technology — Electronic discovery
[38] ISO/IEC TS 27110, Information technology, cybersecurity and privacy protection — Cybersecurity framework development guidelines
[39] ISO/IEC 27701, Security techniques — Extension to ISO/IEC 27001 and ISO/IEC 27002 for privacy information management — Requirements and guidelines
[40] ISO 27799, Health informatics — Information security management in health using ISO/IEC 27002
[41] ISO/IEC 29100, Information technology — Security techniques — Privacy framework
[42] ISO/IEC 29115, Information technology — Security techniques — Entity authentication assurance framework
[43] ISO/IEC 29134, Information technology — Security techniques — Guidelines for privacy impact assessment
[44] ISO/IEC 29146, Information technology — Security techniques — A framework for access management
[45] ISO/IEC 29147, Information technology — Security techniques — Vulnerability disclosure
[46] ISO 30000, Ships and marine technology — Ship recycling management systems — Specifications for management systems for safe and environmentally sound ship recycling facilities
[47] ISO/IEC 30111, Information technology — Security techniques — Vulnerability handling processes
[48] ISO 31000:2018, Risk management — Guidelines
[49] IEC 31010, Risk management — Risk assessment techniques
[50] ISO/IEC 22123 (all parts), Information technology — Cloud computing
[51] ISO/IEC 27555, Information security, cybersecurity and privacy protection — Guidelines on personally identifiable information deletion
[52] Information Security Forum (ISF). The ISF Standard of Good Practice for Information Security 2020, August 20??r）Available at https://www.securityforum.org/tool/standard-of-good-practice-for-information-security-2020/
[53] ITIL? Foundation, ITIL 4 edition, AXELOS, February 2019, ISBN: 9780113316076
[54] National Institute of Standards and Technology (NIST), SP 800-37, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, Revision 2. December 2018 [viewed 2020-07-31]. Available at https://doi.org/10.6028/NIST.SP.800-37r2
[55] Open Web Application Security Project (OWASP). OWASP Top Ten - 2017, The Ten Most Critical Web Application Security Risks, 2017 [viewed 2020-07-31]. Available at https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/
[56] Open Web Application Security Project (OWASP). OWASP Developer Guide, [online] [viewed 2020-10-22]. Available at https://github.com/OWASP/DevGuide
[57] National Institute of Standards and Technology (NIST), SP 800-63B, Digital Identity Guidelines; Authentication and Lifecycle Management. February 2020 [viewed 2020-07-31].Available at https://doi.org/10.6028/NIST.SP.800-63b
[58] OASIS, Structured Threat Information Expression. Available at https://www.oasis-open.org/standards#stix2.0
[59] OASIS, Trusted Automated Exchange of Indicator Information. Available at https://www.oasis-open.org/standards#taxii2.0
