b）特定系统的安全要求

应遵循以下过程来确定安全要求： a）确认资产和可接受的风险等级 b）初步风险评估： 1）确认资产威胁和风险； 2）确定风险事件的可能性和影响： 3）确定未缓解的网络安全风险； 4）定义系统安全等级。 C 建立安全要求。 d 进行多轮风险评估： 1）评估当前措施； 2）重新评估风险事件的可能性和影响； 3）确定剩余风险。 e 记录网络安全要求、假设和约束 每当对系统进行更改或威胁情况发生显著的变化，例如发布新的软件漏洞时，应根据测试结果 更新风险评估结果。 2一宝人金求计和的气金业

6.2.3.1确认资产和系统

a）确认资产以了解系统的哪些部分应受到保护，即哪些部分已被证明需要投入额外成本获得保护 b 从安全角度来看，对企业具有感知或实际价值的所有内容都是资产。资产可以是逻辑或物理对 象，例如服务的可用性、乘客和服务技术人员的安全、安全系统的完整性等； C 必须考虑系统中的附加资产； d 对于电梯、自动扶梯和自动人行道系统，乘客和服务技术人员的安全应视为受保护的资产地基标准规范范本，并 优先于其他保护方面。安全措施不应对电梯、自动扶梯和自动人行道系统的安全功能产生不良 影响； e 在确认资产过程中，应确定可接受的风险级别。可接受级别取决于企业和当地法规规章以及社 会价值等，例如安装在低风险住宅建筑、医院、大使馆中的电梯、自动扶梯和自动人行道系统。 如果需要进行风险评估，则应先定义电梯、自动扶梯和自动人行道系统的典型应用。

6.2.3.2初始风险评估

a）在风险评估过程中，应确定威胁资产的风险事件和风险威胁； 初始风险评估的第一步是确定风险，但无需采取任何缓解措施； ? 电梯、自动扶梯和自动人行道系统的安全威胁包括但不限于： 1）因软件错误引发的漏洞； 2）恶意软件，例如通过网络、可移动存储设备、临时连接的服务工具等传播的蠕虫和病毒； 3）非法访间； 4）员工或他人的未授权的行为； 5）员工的无意行为：

T/CEA 7032020

T/CEA 7032020

注”如果影响全国或全球，则将严重程度提高两级

根据仪始风分析结果确定木减轻的资产风。基于风险矩阵，应确定明些风险需要额外的缓解指 施。安全等级参见第6章中的要求。

6. 2. 3. 3 安全要求

a）在初始风险评估之后，应送 可接受风险等级的评估风险 创建、选择的措施最佳方法是“深度防御”。措施不应依靠单一的防护，而是需要利用多层保护， 如果一种防护被突破，资产仍会受到其他几种防护的保护； 补偿措施可被用于满足一个或多个安全要求，例如物理访问控制或检测控制等； d）有关措施的要求参见第8章，

6. 2.3. 4 进行多轮风险评估

a）如初步风险评估一样进行多轮风险评估，但应落实先前选择的措施； b 检查之前定义的措施是否将已确认的网络安全风险降低到之前定义的可接受水平，还应检查措 施是否会带来新的安全威胁，例如拒绝服务、新的攻击层面等。如果没有降低至可接受水平， 应采取其他措施、缓解方法，并重新评估相关风险； C 当对现有产品或系统的风险评估结束时，应确定所需的缓解措施，以最大限度地降低初始评估 期间发现的风险

6.2.3.5记录网络安全要求

记录网络安全要求如下： a）应包含在开发期间实施的满足安全要求的安全措施。安全要求应对之前确定的安全风险具有可 追溯性； b）追踪并在开发结束时确认和验证所有其他安全要求

6.2.3.6外部开发的软件安全

上述方法应扩展到外部资源开发的组件，包括商务现货供应（COTS）软件、开源软件（OSS） 为公司开发的组件。

T/CEA 7032020

设计阶段的目标是开发系统架构。在该阶段，将确定有关高级设计选择和关键组件的所有决策。在 构开发过程中，为了实现符合所需功能的架构，应对产品的完整功能进行必要的描述。例如，这一描 可能包含所涉及的实体、由此所产生的数据流、已经分配的重要安全或非安全的属性。 由于在设计阶段确认的选择具有深远影响，因此该阶段特别容易出现安全漏洞。开发体系结构中的 陷，可能直接或间接导致在此高级阶段中出现难以识别的漏洞，其原因是它们可能非常特殊或仅在较 等级阶段才能被发现。在设计阶段应尽早定性这些安全问题，这才是最为有效的措施。如果在后期阶 发现安全漏洞，例如在测试或运行期间，则处理会变得更加复杂，处理成本更加昂贵。因此，检测设 阶段已有的漏洞并采用行业标准最佳方法来减少暴露的攻击面是非常重要的。 方法如下： a）最小权限原则，即过程或用户在设计上不应拥有比完成其任务所需的更高权限； b 攻击层面的识别及最小化： 模块化设计，以减少安全威胁的影响； d 深度防御，是指不应通过单一措施，而是通过多项分层措施减轻风险。即使其中一项措施失败， 但其他措施仍然有效； 限制用户的访问权限，仅对接那些满足相应功能的系统或任务所需的数据； 优先使用简单、经过验证的概念或组件，而不是那些不必要的复杂的、专有或未经过充分测试 的组件； 定期执行安全设计审核，以检测当前设计尚未解决的安全要求，并检查系统当前架构是否符合 最佳方法。

至少应遵循以下与安全实施相关的主要属性： a) 使用安全编码标准； 使用静态分析工具； c）关键功能的单元测试； d）分析第三方和开源软件。

T/CEA 7032020

使用安全编码标准，标准应根据实际案例，列出可能被利用的编码结构或不应使用的设计。通常标 隹还应包括禁用、弃用功能列表。 使用静态分析工具，至少使用静态代码工具来分析满足以下条件的代码： a 侦听或连接到网络的代码，这些代码被规划连接到可信、安全区域外部的设备、系统或应用程 序； b 已被确认的早期漏洞代码： c) 需要高权限才能执行的代码，除非所有这些代码都需要高权限才能执行，例如系统最高权限、 管理员账户、根账户等。以高权限运行的代码都应有正当理由； d) 安全相关代码模块，例如身份验证、授权、加密和防火墙代码等； e 解析来自不可信来源的数据结构的代码； f 设置访问控制、处理加密密钥或密码的设置代码； g 应通过静态分析工具降低违反编码标准的所有可识别的风险，除非这些违反标准是没有风险的 h 最佳方法是在开发过程中进行持续的源代码分析，当开发人员输入代码时，会自动分析代码以 查找任何可能的安全问题，

除了产品开发中的正常测试和验证过程之外，网络安全验证和测试计划也应成为系统验证阶段的正 式过程。以下是与安全相关的关键活动

对应用程序应执行动态测试，以识别存储损坏、竞争条件、用户权限问题以及任何其他严重的 题。

对处理源自安全区域或组件外的数据的所有组件，应进行模糊测试 应创建一个模糊测试计划，记录将要执行的模糊测试。该计划应包括将被模糊测试的所有组件 如何进行模糊测试的描述，是否进行智能模糊测试或傻瓜模糊测试以及测试的通过和失败标

除使用模糊测试工具外，建议在测试期间使用各种渗透测试工具。测试计划应包含使用渗透测 相关的详细的所有项目。 应定期考虑独立的（第三方）渗透测试。

以下是验证威胁模型的措施是否已正确实施： a 应对所有组件执行破坏性测试和已知漏洞测试，并尝试利用已减少的威胁模型中确认的所有威 胁； b) 确认威胁建模过程中未捕获的任何攻击面： C) 应仔细地记录结果： d）应通过测试验证实施的安全措施的有效性， / 更新风险评估

6.5.5独立的第三方分析

建议进行独立的第三方安全风险分析和测试，应由已通过充分审核的具有分析资质的机构，进行此 类分析。

在产品发布之前，下列文档和风险接受建议应是已完成并可交付的！ 文件如下所列：

威胁模型需要包含已确认的剩余风险。

6.6.2安全要求和安全设讯

6.6.3安全测试计戈

T/CEA 7032020

报告总结已进行分析的结果并突出任何已发现的问题和不安全的、完善的管控措 a) 第三方代码、库分析报告； b）动态安全分析报告； c静态代码分析报告。

a）模糊测试报告； b）内部渗透测试报告； c）外部渗透测试报告。

6. 6. 6 用户手册

用户手册包括用户、操作和维护手册等，应由相关专家进行审核，并应包括针对用户和管理员的安 全指导部分，包括防止安全漏洞所必需的操作和约束。 管理员标准应包括产品安全操作所需的所有管理员职责，包括与产品安全环境声明中的相关的假设 的管理员行为。 如果提供了可供开发人员创建应用程序的API（应用程序编程接口）、类、对象，则应为每个应用 的函数或方法调用提供安全信息和最佳方法。 用户手册中的安全指南应包含安全漏洞报告过程。 文件应包括设计中假设的威胁配置文件以及与用户相关的高级安全功能，包括身份验证机制、身份 验证和其他功能的默认筛略，以及强制或可选的任何安全协议

6. 6. 7 安全系统安装指南

安装指南应列出并说明系统申存在的所有安全配置选项，并记录其默认和可选设置。因为无任何其 他配置更改的默认配置被视为是安全的，所以安全系统的默认安装是安全的。 此外，安装手册应包含在调试之前要执行的所有现场、外部测试要求，从而完成安全的安装。

6.6.8事故响应计划

在维护服务的情况下，暴露在威胁下的设备的运营要求应有追踪所有暴露的硬件和软件、监视安装 和响应计划等措施。 应评估当前的安装风险，需了解可能暴露给攻击者的所有组件。以下资产清单应包括硬件以及软件 a）保持对正在使用的硬件、软件的库存和版本控制：

T/CEA 7032020

T/CEA 7032020

b）持续监测漏洞数据库和现场问题； c）如果检测到软硬件资产的某个漏洞，则应分析该漏洞对资产造成的任何影响。 如果资产受到漏洞的影响，应通过实施针对此漏洞的更新、替换、减轻或接受风险，解决此问题的 进一步过程。建议使用评分系统，来确定任何已确认的安全问题的优先级并进行评估，

如本文件第6.2章节所述，应在风险评估期间确定系统、组件或区域的安全等级目标，应通过测试 验证系统、组件或区域所达到的安全等级， 在以下情况中，应在系统生命周期内重新进行安全等级的确认： a）对系统进行更改； 检测到与系统相关的新漏洞； C 供应商或开源社区发布了系统组件新的安全补丁： 定期，由机构政策决定 e）安全等级（SL）用于描述为抵御网络攻击的技术等级和动机

SL0定义：无特定要求或必需的安全保护措施 通过风险评估，确定系统不需要特定的安全要求，例如：因为误用的后果被确定为可以忽略不计 在评估是否已达到安全等级时，SLO0可表示已实施SL1的一部分措施，但未满足完整的SL1的等级。

SL1定义：能够抵御业余或偶尔的入侵 应能保护系统免受低技能攻击或无意、误用的攻击。应采取基本的安全控制措施以确保数据的保密 性、完整性和可用性，并实施访问身份的验证、授权和记录。例如根据SL1所采取的安全控制，不需要 对用户和设备进行唯一性认证。

T/CEA 7032020

SL2定义：防止使用需要少量资源、通用技能和低动机的简单方式的故意入侵 系统应能抵御具有盗用通用信息技术系统的工具和技能的攻击，例如：基于网络的应用程序。但攻 击者不具备电梯、自动扶梯和自动人行道系统的专业知识，且不专门针对这些系统进行攻击。攻击者的 动机可能是获得金钱收益或声誉收益等，例如勒索软件。与SL1的不同之处在于，SL2保护措施是更细致 的安全控制措施。例如应对用户和设备的唯一性进行身份验证。 本文件第8章描述了SL2的建议控制措施

SL3定义：防止使用需要中等资源、特定电梯、自动扶梯和自动人行道的技能和中等动机的复杂手 段的故意入侵。 系统应能够抵御技能高超、了解安全措施和电梯、自动扶梯和自动人行道系统并且专门针对此类系 统的攻击者。以SL3系统为目标的攻击者可能会使用针对特定目标系统定制的攻击媒介。攻击者的动机 可能是勒索、报复或破坏，例如心怀不满的前雇员、行业竞争对手等。 SL3的控制措施超出了本文件的范围

SL4定义：防止使用需要扩展资源、特定电梯、自动扶梯和自动人行道的技能和强烈动机的故意入 侵。 系统应能够抵御技能高超、了解安全措施及电梯、自动扶梯和自动人行道系统并且专门针对具有扩 展资源和强烈动机的系统的攻击者。这与SL3类似，但SL4的攻击者动机更高并准备花更长的时间、资源 来规划和执行攻击。 SL4的控制措施超出了本文件的范围，

T/CEA 7032020

强化标准中的关键要素包括对所 对防病毒和反间谋软件进行良好的维护、 支时更新补了、打开软件防火墙选项 范围内。此类强化标准由NIST和其他组 织发布，建议任何使用服务 尖标准

设备安装施工组织设计 T/CEA 7032020

A.1.3初步风险评估

a）确认资产威胁和风险 1) 对监测系统的拒绝服务攻击； 2) 篡改监测系统发送的数据； 3) 伪装成监测系统发送数据； 4） 获得监测系统的所有权； 5） 通过监测系统攻击控制系统 b）确定可能性和影响（见表A.1）

表 A. 1 风险评估

c）确定未缓解的网络安全风险 由于监测系统将通过互联网连接，因此可扩展攻击是一个需要考虑的安全威胁。因此，风险评估必 须假设攻击者可以同时攻击多个节点，如表A.2所示。

医疗器械标准表A.2可扩展攻击的网络安全风险