Security Extract
参考文献¶
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_RS_Main
1. 引言¶
1.1. 本文档的范围¶
本文档收集对安全提取模板（Security Extract Template）的需求。
安全提取（Security Extract）的主要目的是定义安全事件（Security Event）及其属性，作为车辆电子电气入侵检测系统（IDS）的输入。安全提取可以作为交换文件，在开发过程中以及车辆已在现场运行时的维护过程中，从多个来源收集安全事件及其属性。
安全提取文件用于配置车辆 ECU 或机器（Machine）中入侵检测系统管理器（IdsM）实例的安全事件。
它还可以进一步用作（例如）「安全事件与事件管理」（SIEM）系统的输入，作为「安全运营中心」（SOC）的一部分，以便解读从车辆的 IdsM 实例接收到的二进制数据。
简而言之，使用安全提取的关键方面是：
- 在开发过程中从多个来源收集安全事件定义
- 作为车辆 ECU 与机器的 IdsM 实例的安全事件配置的输入
- 作为 SIEM 系统的输入，以便解读与安全事件相关的二进制数据
1.2. 文档约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章（[1]）。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章（[1]）。
1.3. 指南¶
应引用既有规范（以单一需求的形式）。与这些规范的差异作为附加需求规定。
所有需求应具有以下属性：
- 冗余性（Redundancy）
需求不得在一个需求内部或其他需求中重复。
- 清晰性（Clearness）
所有需求只允许一种解释。使用的、术语表中没有的技术术语必须加以定义。
- 原子性（Atomicity）
每个需求应只包含一条需求。如果一个需求无法再拆分为更多需求，则该需求是原子的。
- 可测试性（Testability）
需求应能够通过分析、评审或测试加以检验。
- 可追溯性（Traceability）
需求的来源和状态应始终可见。
2. 需求¶
2.1. 与安全事件相关的需求¶
2.1.1. 安全事件的定义¶
| 描述 | 安全提取应支持安全事件的定义和配置。 |
|---|---|
| 理由 | 应能够将与安全相关的事件及其关联信息从传感器（以硬件或软件实现）传递给处理这些事件及其关联信息的软件模块。 |
| 用例 | 上报一个安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.2. 为安全事件定义安全传感器 ID¶
| 描述 | 安全提取应支持为安全事件定义安全传感器 ID。 |
|---|---|
| 理由 | 应能够将安全事件与安全传感器的数字标识符关联。 |
| 用例 | 识别安全事件的来源 |
| 依赖项 | - |
| 支撑材料 |
2.1.3. 支持安全事件的可选上下文数据¶
| 描述 | 安全提取应支持定义特定于安全事件的可选上下文数据。 |
|---|---|
| 理由 | 应能够配置：给定的安全事件附带附加上下文数据上报。 |
| 用例 | 附带附加上下文数据上报一个安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.4. 安全事件的过滤链¶
| 描述 | 安全提取应支持为安全事件定义过滤链。 |
|---|---|
| 理由 | 应能够为安全事件串联过滤器，以实现由多种算法组成的多级过滤。 |
| 用例 | 过滤安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.5. 安全事件的限制过滤¶
| 描述 | 安全提取应支持为安全事件定义限制过滤器。 |
|---|---|
| 理由 | 应能够限制安全事件的进一步处理，以防止超出后续处理阶段的能力。 |
| 用例 | 限制安全事件造成的处理负载 |
| 依赖项 | - |
| 支撑材料 |
2.1.6. 安全事件的预鉴定支持¶
| 描述 | 安全提取应支持定义是否为特定安全事件提供预鉴定（pre-qualification）。 |
|---|---|
| 理由 | 作为通过过滤进行鉴定的替代方式，（智能）传感器应能够上报预鉴定的安全事件，这些事件应由 IdsM 直接作为已鉴定的安全事件处理。 |
| 用例 | 上报预鉴定的安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.7. 安全事件与 ECU/机器的关联¶
| 描述 | 安全提取应支持定义安全事件与检测并上报它们的 ECU 之间的关系。 |
|---|---|
| 理由 | 应能够配置：给定的安全事件由给定的 ECU 上报。 |
| 用例 | 在给定的 ECU 上上报一个安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.8. 安全事件与平台模块的关联¶
| 描述 | 安全提取应支持定义安全事件与作为安全问题主体的平台模块之间的关系。平台模块是基础软件模块（经典平台）或功能集群（自适应平台）。 |
|---|---|
| 理由 | 应能够配置：给定的安全事件针对给定的平台模块上报。 |
| 用例 | 针对给定的平台模块上报一个安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.9. 安全事件与通信总线的关联¶
| 描述 | 如果安全事件用于上报与相关通信总线有关的问题，安全提取应支持定义安全事件与该通信总线之间的关系。 |
|---|---|
| 理由 | 应能够配置：给定的安全事件针对给定的通信总线上报。 |
| 用例 | 针对给定的通信总线上报一个安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.10. 安全事件与应用的关联¶
| 描述 | 安全提取应支持定义安全事件与作为安全问题主体的应用（经典平台的软件组件或自适应应用）之间的关系。 |
|---|---|
| 理由 | 应能够配置：给定的安全事件由给定的应用上报。 |
| 用例 | 针对给定的应用上报一个安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.11. 支持安全事件的持久存储¶
| 描述 | 安全提取应支持为给定的安全事件配置持久性。 |
|---|---|
| 理由 | 应能够配置：给定的安全事件集合持久地存储在检测到它们的 ECU 上。 |
| 用例 | 将安全事件存储在检测到它的 ECU 上 |
| 依赖项 | - |
| 支撑材料 |
2.1.12. 安全事件默认上报模式的定义¶
| 描述 | 安全提取应支持为安全事件配置具有不同详细程度的默认上报模式。 |
|---|---|
| 用例 | 以不同的详细程度上报安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.1.13. 支持在安全事件映射时定义严重性等级¶
| 描述 | 安全提取应支持在安全事件映射到 ECU 或机器时，为各个安全事件单独定义严重性等级。 |
|---|---|
| 理由 | 应能够根据安全事件到 IdsM 实例的映射来配置其严重性等级。 |
| 用例 | 附带附加严重性等级信息上报一个安全事件 |
| 依赖项 | - |
| 支撑材料 |
2.2. 与 IdsM 实例相关的需求¶
2.2.1. IdsM 实例的可选配置¶
| 描述 | 安全提取应支持可选地定义并部分配置一个或多个 IdsM 实例，与各个 IdsM 实例将运行于自适应平台还是经典平台无关。 |
|---|---|
| 理由 | 除安全事件之外，安全提取还应为 IdsM 实例的配置作出部分贡献。 |
| 用例 | 可选地定义并部分配置 IdsM 实例 |
| 依赖项 | - |
| 支撑材料 |
2.2.2. 时间戳提供的可选配置¶
| 描述 | 安全提取应支持配置 IdsM 实例是否为上报的安全事件提供时间戳信息，如果提供，该时间戳信息是否为 AUTOSAR 标准化格式。 |
|---|---|
| 理由 | 应可配置 IdsM 实例是否在其上报的安全事件中附加时间戳信息。 |
| 用例 | 可选地为安全事件上报时间戳信息 |
| 依赖项 | - |
| 支撑材料 |
2.2.3. 时间戳格式的配置¶
| 描述 | 安全提取应支持配置 IdsM 在为上报的安全事件附加时间戳信息时使用的格式。时间戳格式可能是 AUTOSAR 标准化的、由其他机构标准化的、企业标准化的或任意定义的。 |
|---|---|
| 理由 | 预期不同企业和项目会对上报的安全事件使用不同的时间戳格式。 |
| 用例 | 以可配置的格式上报时间戳信息 |
| 依赖项 | - |
| 支撑材料 |
2.2.4. 安全事件消息认证提供的可选配置¶
| 描述 | 对于 AUTOSAR 经典平台和自适应平台两者，安全提取应支持可选地配置：要求 IdsM 实例向其发送到网络的所有安全事件消息添加认证信息（即签名）。 |
|---|---|
| 理由 | 安全提取应在网络配置方面支持 IdsM 实例配置。 |
| 用例 | 可选地定义并部分配置自适应平台上的 IdsM 实例 |
| 依赖项 | - |
| 支撑材料 |
2.2.5. 网络配置与 IdsM 实例的关联¶
| 描述 | 对于 AUTOSAR 经典平台和自适应平台两者，安全提取模板应描述如何定义 IdsM 实例与其网络配置的关联。 |
|---|---|
| 理由 | 安全提取应在网络配置方面支持 IdsM 实例配置。 |
| 用例 | 可选地定义并部分配置一个 IdsM 实例 |
| 依赖项 | - |
| 支撑材料 |
2.3. 与 AUTOSAR 方法论相关的需求¶
2.3.1. 支持 IDS 作用域和系统边界的定义¶
| 描述 | 安全提取应支持定义处于设计和实现中的 IDS 的作用域（即系统边界）。 |
|---|---|
| 理由 | 一个 IDS 设计通常涉及车辆内所有 ECU 的一个子集。该子集中的每个 ECU 应能够上报单独定义和/或适配的安全事件。因此，为了开发 IDS，安全提取需要能够定义属于一个 IDS 的所有系统部分以及这些 IDS 系统部分的特定系统级能力。 |
| 用例 | IDS 的系统级描述 |
| 依赖项 | - |
| 支撑材料 |
2.3.2. 支持安全提取定义的部分和完整交换¶
| 描述 | 安全提取应支持其定义在开发伙伴之间的部分交换和完整交换。 |
|---|---|
| 理由 | 为了实现 IDS 的分布式开发，多个开发伙伴共同为一个描述整个 IDS 设计的安全提取文件作贡献。这些贡献者需要能够在 IDS 设计允许的范围内，尽可能独立于其他人地指定他们负责的安全提取部分。 |
| 用例 | IDS 的分布式开发 |
| 依赖项 | - |
| 支撑材料 |
2.3.3. 相关 ECU-C 参数的推导¶
| 描述 | 安全提取应支持为 IdsM 模块推导与安全事件相关的 ECU-C 参数。 |
|---|---|
| 理由 | 安全提取处于系统（M2）层级，必须提供所需信息，以推导 ECU 的 IdsM 模块中与安全事件相关的配置参数（M1 层级）。因此，按照 AUTOSAR 方法论，其用法与诊断提取（Diagnostic Extract）或 ECU 提取类似。 |
| 用例 | 为 IdsM 推导 ECU-C 配置参数 |
| 依赖项 | - |
| 支撑材料 |
2.3.4. AUTOSAR 标准化安全事件的规范¶
| 描述 | 安全提取应支持 AUTOSAR 标准化安全事件的规范。 |
|---|---|
| 理由 | 随着入侵检测系统管理器的引入，AUTOSAR 还将为既有 BSW 模块（经典平台）或功能集群（自适应平台）提供标准化的安全事件。这些标准化的安全事件应使用安全提取模板加以规范，以支持文档生成的自动处理（单一来源原则）。 |
| 用例 | 规范 AUTOSAR 标准化的安全事件 |
| 依赖项 | - |
| 支撑材料 |
A. AUTOSAR 可追溯项变更历史¶
A.1. 本文档依据 AUTOSAR R20-11 的可追溯项变更历史¶
A.1.1. R20-11 中新增的需求¶
表A.1：R20-11 中新增的需求
| 标题 |
|---|
| 安全事件（Security Event） |
| 安全事件过滤（Security Event Filtering） |
| 安全事件与 Ecu 的关联（Association of Security Event with an Ecu） |
| 安全事件与通信总线的关联（Association of Security Event with a communication bus） |
| 支持安全事件的持久存储（Support the persistent storage of security events） |
| 支持安全事件的不同上报模式（Support different reporting modes for security events） |
| 安全事件与基础软件模块的关联（Association of Security Event with a basic software module） |
A.1.2. R20-11 中变更的需求¶
无
A.1.3. R20-11 中删除的需求¶
无
A.2. 本文档依据 AUTOSAR R22-11 的可追溯项变更历史¶
A.2.1. R22-11 中新增的需求¶
无
A.2.2. R22-11 中变更的需求¶
无
A.2.3. R22-11 中删除的需求¶
无
A.3. 本文档依据 AUTOSAR R23-11 的可追溯项变更历史¶
A.3.1. R23-11 中新增的需求¶
无
A.3.2. R23-11 中变更的需求¶
无
A.3.3. R23-11 中删除的需求¶
无