ISO/IEC JTC1 SC27

 信息安全、网络安全和隐私保护—信息安全控制

ISO/IEC 27002:2022

 (中文版)

 翻译：闲庭信步

 2022年7月

8 技术控制

8.1 用户终端设备

控制

应保护在用户终端设备上存储、处理或访问的信息。

目的

保护信息免受使用用户终端设备带来的风险。

指南

一般原则

组织应针对用户终端设备的安全配置和处理建立特定主题政策。应将特定主题政策传达给所有相关人员，并考虑以下事项：

a) 用户终端设备可以处理、加工、存储或支持的信息类型和分类级别；

b) 用户终端设备的注册；

c) 物理保护要求；

d) 软件安装的限制(例如由系统管理员远程控制)；

e) 对用户终端设备软件(包括软件版本)和应用更新(例如主动自动更新)的要求；

f) 有关连接到信息服务、公共网络或任何其他场外网络的规则(例如，要求使用个人防火墙)；

g) 访问控制；

h) 存储设备加密；

i) 防范恶意软件；

j) 远程禁用、删除或锁定；

k) 备份；

l) web服务和web应用程序的使用；

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) 仅使用具有特权访问权限的身份来执行管理任务，而不是用于日常的一般任务[即检查电子邮件、访问web(用户应该为这些活动拥有一个独立的正常网络身份)]。

其他信息

特权访问权限是提供给身份、角色或进程的访问权限，允许执行典型用户或进程无法执行的活动。系统管理员角色通常需要特权访问权限。

不恰当地使用系统管理员权限(使用户能够覆盖系统或应用程序控制的信息系统的任何功能或设施)是导致系统故障或破坏的主要原因。

有关访问管理和对信息以及信息和通信技术资源的访问安全管理的更多信息，请参见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) 如果检测到滥用信息的企图，则发出警报。

其他信息

动态访问管理技术和其他动态信息保护技术可以支持信息保护，即使数据在原始组织之外共享以致传统的访问控制无法实施。它可以应用于文档、电子邮件或其他包含信息的文件，以限制谁可以访问内容以及以何种方式访问内容。它可以是细粒度的，并且可以在信息的整个生命周期中进行调整。

动态访问管理技术不会取代传统的访问管理[例如使用访问控制列表(ACL)]，但可以为条件性、实时评估、实时数据减少和其他对最敏感信息有用的增强功能添加更多因素。它提供了一种控制组织环境外部访问的方法。动态访问管理技术可以支持事件响应，因为可以随时修改或撤销权限。

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) 从内部或外部来源接收漏洞报告。

作为关于漏洞披露的特定主题政策的一部分，组织应提供一个公共联络点，以便研究人员和其他人能够报告问题。组织应建立漏洞报告程序、在线报告表格并利用适当的威胁情报或信息共享论坛。组织还应该考虑漏洞奖励计划，即提供奖励，以帮助组织识别漏洞，以便适当地修复它们。该组织还应与主管行业机构或其他相关方共享信息。

评估技术漏洞

为了评估已识别的技术漏洞，应考虑以下指南：

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函数结合使用。

资源标识符及其属性中的PII[例如文件名、统一资源定位器(URL)]应避免或适当匿名。

ISO/IEC 27018中提供了有关保护公共云中PII的其他控制措施。

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 TS23167中讨论了在云服务环境中提供冗余和自动故障转移的一些技术和技巧。

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)或防火墙规则，以及入侵检测系统(IDS)或恶意软件签名]；

e) 与异常活动和行为相比的已知行为模式和标准网络流量[用户和实体行为分析(UEBA)]；

f) 趋势或模式分析的结果(例如，使用数据分析、大数据技术和专业分析工具的结果)；

g) 可用的威胁情报。

日志分析应得到特定监控活动的支持，以帮助识别和分析异常行为，其中包括：

a) 审查访问受保护资源的成功和不成功尝试[例如域名系统(DNS)服务器、门户网站和文件共享]；

b) 检查DNS日志以识别到恶意服务器的出站网络连接，例如与僵尸网络命令和控制服务器相关的那些；

c) 检查来自服务提供商的使用报告(例如票据或服务报告)是否存在系统和网络内的异常活动(例如通过审查活动模式)；

d) 包括入口和出口等物理监控的事件日志，以确保更准确的检测和事件分析；

e) 关联日志以实现高效和高度准确的分析。

f) 应识别疑似和实际的信息安全事件(例如恶意软件感染或防火墙探测)并接受进一步调查(例如作为信息安全事件管理过程的一部分，见5.25)。

其他信息

系统日志通常包含大量信息，其中大部分与信息安全监控无关。为了帮助识别用于信息安全监控目的的重要事件，可以考虑使用合适的实用程序或审计工具来执行文件询问。

事件记录为能够生成关于系统安全的综合报告和警报的自动监控系统(见8.16)奠定了基础。

SIEM工具或等效服务可用于存储、关联、规范化和分析日志信息，并生成警报。SIEM往往需要仔细配置以优化其优势。

要考虑的配置包括识别和选择适当的日志源、调整和测试规则以及开发用例。

应使用用来记录日志的公共透明文件，例如，在证书透明系统中。这样的文件可以提供一个额外的检测机制，以防止日志篡改。

在云环境中，日志管理职责可以在云服务客户和云服务提供商之间共享。责任因所使用的云服务类型而异。进一步的指导可以在ISO/IEC 27017中找到。

8.16 监控活动

控制

应监控网络、系统和应用程序的异常行为，并采取适当措施评估潜在的信息安全事件。

目的

检测异常行为和潜在的信息安全事件。

指南

监控范围和级别应根据业务和信息安全要求并结合相关法律法规确定。监测记录应在规定的保留期限内保存。

应考虑将以下内容纳入监测系统：

a) 出站和入站网络、系统和应用流量；

b) 访问系统、服务器、网络设备、监控系统、关键应用等；

c) 关键或管理级别的系统和网络配置文件；

d) 来自安全工具的日志[例如：防病毒、IDS、入侵防御系统(IPS)、Web过滤器、防火墙、数据泄露防护]；

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) 如果网络受到攻击，则临时隔离关键子网(例如使用drawbridges)；

n) 禁用易受攻击的网络协议。

组织应确保对虚拟化网络的使用应用适当的安全控制。虚拟化网络还涵盖软件定义网络(SDN、SD-WAN)。从安全的角度来看，虚拟化网络可能是可取的，因为它们可以允许在物理网络上进行通信的逻辑分离，特别是对于使用分布式计算实现的系统和应用程序。

其他信息

有关网络安全的更多信息，请参见ISO/IEC 27033系列。

有关虚拟化网络的更多信息，请参见ISO/IEC TS23167。

8.21 网络服务的安全

控制

应确定、实施和监控网络服务的安全机制、服务级别和服务要求。

目的

确保使用网络服务的安全。

指南

应(由内部或外部网络服务提供商)确定和实施特定服务所需的安全措施，例如安全特性、服务级别和服务要求。组织应确保网络服务提供商实施这些措施。

应确定并定期监控网络服务提供商以安全方式管理约定服务的能力。审核权应在组织和提供者之间达成一致。组织还应考虑服务提供商提供的第三方证明，以证明他们保持适当的安全措施。

应制定并实施关于网络和网络服务的使用规则，包括：

a) 允许访问的网络和网络服务；

b) 访问各种网络服务的认证要求；

c) 确定允许谁访问哪些网络和联网的授权程序；

d) 网络管理、技术控制和程序，以保护对网络连接和网络服务的访问；

e) 用于访问网络和网络服务的手段[例如使用虚拟专用网络(VPN)或无线网络]；

f) 用户在访问时的时间、地点和其他属性；

g) 网络服务的使用监控。

应考虑网络服务的以下安全特性：

a) 应用于网络服务安全的技术，例如认证、加密和网络连接控制；

b) 按照安全和网络连接规则与网络服务进行安全连接所需的技术参数；

c) 缓存(例如在内容交付网络中)及其参数，允许用户根据性能、可用性和机密性要求选择缓存的使用；

d) 必要时限制对网络服务或应用程序访问的网络服务使用程序。

其他信息

网络服务包括提供连接、专用网络服务和托管网络安全解决方案，例如防火墙和入侵检测系统。这些服务的范围从简单的非托管带宽到复杂的增值产品。

ISO/IEC 29146中提供了有关访问管理框架的更多指南。

8.22 网络隔离

控制

信息服务组、用户组和信息系统组应在组织的网络中隔离。

目的

在安全边界上分割网络，并根据业务需求控制它们之间的流量。

指南

组织应考虑通过将大型网络划分为单独的网络域并将它们与公共网络(即互联网)分开来管理大型网络的安全性。可以根据信任级别、关键性和敏感性(例如公共访问域、桌面域、服务器域、低风险和高风险系统)以及组织单位(例如人力资源、财务、营销)或某种组合来选择域(例如连接到多个组织单位的服务器域)。可以使用物理上不同的网络或使用不同的逻辑网络来完成隔离。

每个域的边界应该明确定义。如果允许网络域之间的访问，则应使用网关(例如防火墙、过滤路由器)在外围对其进行控制。将网络划分为域的标准，以及通过网关允许的访问，应基于对每个域的安全要求的评估。评估应符合关于访问控制的特定主题政策(见5.15)、访问要求、处理信息的价值和分类，并考虑结合适当网关技术的相对成本和性能影响。

由于网络边界不明确，无线网络需要特殊处理。无线网络的隔离应考虑无线电覆盖调整。对于敏感环境，应考虑将所有无线访问视为外部连接，并将此访问与内部网络隔离，直到访问根据网络控制(见8.20)通过网关，然后才授予对内部系统的访问权限。如果员工仅使用符合组织特定主题政策的受控用户终端设备，则应将访客无线接入网络与员工无线接入网络隔离开。访客WiFi应至少具有与员工WiFi相同的限制，以阻止员工使用访客WiFi。

其他信息

网络通常延伸到组织边界之外，因为形成了需要互连或共享信息处理和网络设施的业务伙伴关系。此类扩展可能会增加未经授权访问使用网络的组织信息系统的风险，其中一些由于其敏感性或重要性而需要其来自他网络用户的保护。

8.23 网页过滤

控制

应管理对外部网站的访问，以减少面临恶意内容的可能。

目的

保护系统免受恶意软件的破坏并防止访问未经授权的Web资源。

指南

组织应降低员工访问包含非法信息或已知包含病毒或网络钓鱼诱饵的网站的风险。有一种通过屏蔽相关网站的IP地址或域的技术可以实现这一目的。一些浏览器和反恶意软件技术会自动执行此操作或可以配置为执行此操作。

组织应确定人员应该或不应该访问的网站类型。组织应考虑阻止访问以下类型的网站：

a) 具有信息上传功能的网站，除非出于正当的商业原因允许；

b) 已知或可疑的恶意网站(例如分发恶意软件或网络钓鱼内容的网站)；

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)。

其他信息

开发也可以在应用程序内部进行，例如办公应用程序、脚本、浏览器和数据库。

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应用程序容易受到由糟糕的设计和编码引入的各种漏洞的影响，例如数据库注入和跨站点脚本攻击。在这些攻击中，可以操纵请求以滥用网络服务器功能。

有关ICT安全评估的更多信息，请参阅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)。

其他信息

可以建立多个测试环境，用于不同类型的测试(例如功能和性能测试)。这些不同的环境可以是虚拟的，通过单独的配置来模拟各种操作环境。

还需要考虑对测试环境、工具和技术的测试和监控，以确保有效的测试。同样的考虑也适用于部署在开发、测试和生产环境中的监控系统的监控。需要根据系统和数据的敏感性进行判断，以确定有多少层元测试是有用的。

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) 测试的证据和变更测试的接受(见8.29)；

d) 变更授权；

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 概述

本附件提供了一个表格来演示如何使用属性创建不同视图的控制。这些属性的使用示例如下：

a) 控制类型(#Preventive预防、#Detective检测、#Corrective纠正)

该属性可用作组织检查已确定控制的平衡的一种手段；例如，可以有足够的控制来检测信息安全事件，但没有足够的控制来防止信息安全事件。

b) 信息安全属性(#Confidentiality机密型、#Integrity完整性、#Availability可用性)

当组织想要了解每个控制的属性时，可以使用此属性，例如，控制是否有助于保护信息的所有机密性、完整性和可用性，或者仅有助于这些属性中的一个或两个。

c) 网络安全概念(#Identify识别、#Protect保护、#Detect检测、#Respond响应、#Recover恢复)

当组织在组织内同时建立信息安全管理系统(ISMS)和网络安全框架，并希望了解本文档中描述的ISMS控制与ISO中描述的网络安全框架的五个概念之间的相关性时，可以使用此属性/IEC TS 27110。

d) 操作能力(#Governance治理、#Asset management资产管理、#Information protection信息保护、#Human resource security人力资源安全、#Physical security物理安全、System and network security系统和网络安全、#Application security应用安全、#Secure configuration安全配置、#Identity and access management身份和访问管理、#Threat and vulnerability management威胁和漏洞管理、#Continuity连续性、#Supplier relationships security供应商关系安全、#Legal and compliance法律和合规、#Information security event management信息安全事件事件、#Information security assurance信息安全保障)

当组织想要从从业者的角度对控制进行分类时，可以使用此属性；例如，当组织想要根据这些属性值分配组织内的负责部门时。

e) 安全域(#Governance and Ecosystem治理与生态系统、#Protection保护、#Defence防御、#Resilience恢复力)

当组织想要从信息安全领域、专业知识、服务和产品的角度对控制进行分类时，可以使用此属性。

表A.1包含本文档中所有控件及其给定属性值的矩阵。

矩阵的过滤或排序可以通过使用简单的电子表格或数据库等工具来实现，其中可以包含更多信息，如控制文本、指南、组织特定的指南或属性(见A.2)。

表A.2显示了如何通过按特定属性值(在本例中为#Corrective纠正)过滤来创建视图的示例。

A.2 组织视角

第一步是了解为什么需要组织特定的属性。例如，如果一个组织已经根据事件构建了其风险处理计划[参见ISO/IEC 27001:2013,6.1.3e)]，它可能希望将风险情景属性与本文档中的每个控制相关联。

这种属性的好处是加快实现与风险处理相关的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) 涉及的组织领域(安全、ICT、人力资源、最高管理层等)；

e) 事件；

f) 涉及的资产；

e) 构建和运行，以区分服务生命周期的不同步骤中使用的控件；

g) 组织使用或可以从其过渡的其他框架。

附录B  (信息性)符合ISO/IEC 27002:2013

本附件的目的是为当前使用ISO/IEC 27002:2013标准并希望过渡到该版本的组织提供向后兼容性。

表B.1提供了条款5至8中规定的控制与ISO/IEC 27002:2013中的控制的对应关系。

表B.2提供了ISO/IEC 27002:2013中规定的控制与本文件中规定的对应关系。

参考书目

[1] ISO 9000，质量管理体系—基础知识和词汇

[2] ISO/IEC 11770(所有部分)，信息安全—密钥管理

[3] ISO/IEC 15408(所有部分)，信息技术—安全技术—IT安全评估标准

[4] ISO 15489(所有部分)，信息和文件—记录管理

[5] ISO/IEC 17788，信息技术—云计算—概述和词汇

[6] ISO/IEC 17789，信息技术—云计算—参考架构

[7] ISO/IEC 19086(所有部分)，云计算-服务水平协议(SLA)框架

[8] ISO/IEC 19770(所有部分)，信息技术—IT资产管理

[9] ISO/IEC 19941，信息技术—云计算—互操作性和可移植性

[10] ISO/IEC 20889，隐私增强数据去识别术语和技术分类

[11] ISO 21500，项目、项目群和项目组合管理—背景和概念

[12] ISO 21502，项目、项目群和项目组合管理—项目管理指南

[13] ISO 22301，安全性和弹性—业务连续性管理系统—要求

[14] ISO 22313，安全性和弹性—业务连续性管理系统—ISO 22301使用指南

[15] ISO/TS 22317，社会安全—业务连续性管理系统—业务影响分析指南(BIA)

[16] ISO 22396，安全性和弹性—社区弹性—组织间信息交换指南

[17] ISO/IEC/TS 23167，信息技术—云计算—通用技术和技巧

[18] ISO/IEC 23751-2，信息技术—云计算和分布式平台—数据共享协议(DSA)框架

[19] ISO/IEC 24760(所有部分)，IT安全和隐私—身份管理框架

[20] ISO/IEC 27001:2013，信息技术—安全技术—信息安全管理系统—要求

[21] ISO/IEC 27005，信息技术—安全技术—信息安全风险管理

[22] ISO/IEC 27007，信息安全、网络安全和隐私保护—信息安全管理系统审计指南

[23] ISO/IEC/TS 27008，信息技术—安全技术—信息安全控制评估指南

[24] ISO/IEC 27011，信息技术—安全技术—基于ISO/IEC 27002的电信组织的信息安全控制实践代码

[25] ISO/IEC/TR 27016，信息技术—安全技术—信息安全管理—组织经济学

[26] ISO/IEC 27017，信息技术—安全技术—基于ISO/IEC 27002的云服务信息安全控制实践代码

[27] ISO/IEC 27018，信息技术—安全技术—在充当PII处理器的公共云中保护个人身份信息(PII)的实践代码

[28] ISO/IEC 27019，信息技术—安全技术—能源公用事业行业的信息安全控制

[29] ISO/IEC 27031，信息技术—安全技术—为业务连续性而准备的信息和通信技术指南

[30] ISO/IEC 27033(所有部分)，信息技术—安全技术—网络安全

[31] ISO/IEC 27034(所有部分)，信息技术—应用安全

[32] ISO/IEC 27035(所有部分)，信息技术—安全技术—信息安全事件管理

[33] ISO/IEC 27036(所有部分)，信息技术—安全技术—供应商关系的信息安全

[34] ISO/IEC 27037，信息技术—安全技术—数字证据的识别、收集、获取和保存指南

[35] ISO/IEC 27040，信息技术—安全技术—存储安全

[36] ISO/IEC 27050(所有部分)，信息技术—电子发现

[37] ISO/IEC/TS 27110，信息技术、网络安全和隐私保护—网络安全框架开发指南

[38] ISO/IEC 27701，安全技术—隐私信息管理对ISO/IEC 27001和ISO/IEC 27002的扩展—要求和指南

[39] ISO 27799，健康信息学—使用ISO/IEC 27002的健康信息安全管理

[40] ISO/IEC 29100，信息技术—安全技术—隐私框架

[41] ISO/IEC 29115，信息技术—安全技术—实体认证保证框架

[42] ISO/IEC 29134，信息技术—安全技术—隐私影响评估指南

[43] ISO/IEC 29146，信息技术—安全技术—访问管理框架

[44] ISO/IEC 29147，信息技术—安全技术—漏洞披露

[45] ISO 30000，船舶和海洋技术—船舶回收管理系统—安全和环保的船舶回收设施管理系统规范

[46] ISO/IEC 30111，信息技术—安全技术—漏洞处理过程

[47] ISO 31000:2018，风险管理—指南

[48] IEC 31010，风险管理—风险评估技术

[49] ISO/IEC 22123(所有部分)，信息技术—云计算

[50] ISO/IEC 27555，信息安全、网络安全和隐私保护—个人身份信息删除指南

[51] 信息安全论坛(ISF)。ISF 2020年信息安全良好实践标准，2018年8月。可在https://www.securityforum.org/tool/standard-of-good-practice-for-information-security-2020/获得

[52] ITIL® Foundation，ITIL 4版，AXELOS，2019年2月，ISBN：9780113316076

[53] 美国国家标准与技术研究院(NIST)，SP 800-53B，信息系统和组织的控制基线，修订版5(草案)。2020年7月[查看时间：2020-07-31]。可在https://doi.org/10.6028/NIST.

SP.800-53B-draft获得

[54] 美国国家标准与技术研究院(NIST)，SP 800-37，信息系统和组织的风险管理框架：安全和隐私的系统生命周期方法，修订版2。2018年12月[2020年7月31日查看].可在https://doi.org/10.6028/NIST.SP.800-37r2获得

[55] 开放Web应用程序安全项目(OWASP)。OWASP十大-2017，十大最关键的Web应用程序安全风险，2017[查看时间：2020-07-31]。可在https://owasp.org/www.project-top-ten/

OWASP_Top_Ten_2017/获得

[56] 开放Web应用程序安全项目(OWASP)。OWASP开发人员指南，[在线][于2020年10月22日查看]。可在https://github.com/OWASP/DevGuide获得

[57] 美国国家标准与技术研究院(NIST)，SP 800-63B，数字身份指南；身份验证和生命周期管理。2020年2月[查看时间：2020-07-31]。可在https://doi.org/10.6028/NIST.SP.

800-63b获得

[58] OASIS，结构化威胁信息表达。可在https://www.oasis-open.org/standards#stix2.0获得

[59] OASIS，指标信息的可信自动交换。可在https://www.oasis.open.org/standards#

taxii2.0获得