信息安全、功能安全和其他学科之间的关系
将信息安全技术应用于汽车系统的一个关键点是要结合汽车工程的其他安全方面来考虑。传统的车辆工程基于指定车辆的属性或目标，这些属性或目标通常在设计开发流程的早期进行设置。例如，通过将开发测试活动与可比车辆进行基准测试。这些属性可能是客观存在的（例如，电动汽车 的续航里程或加速时间等）或驾乘人员的主观感受（例如，行驶和操控、噪声和震动等）。然后将这些属性级联并细化为车辆、系统和组件需求的连续级别，以便它们可以在产品中实现。
这种需求及相关的测试和验证活动通常使用系统工程的“V”模型进行管理。当然，在产品开发过程中，可能需要在属性之间进行折衷或权衡（例如，牺牲续航里程的性能，或在乘坐舒适性与操控性之间进行平衡）。
功能安全学科中出现的一个重要原则是，作为安全目标表示的危险分析和风险评估（H&R/HARA）的结果及其相关的汽车安全完整性等级（ASIL）值有效地代表了需要在计划早期定义的属性，以便对实现这些目标所需的产品开发的严格性设定期望。
因此，作为属性（ISO 26262术语中的“项目”），为特定系统指定的安全目标和ASIL总结了所需的性能目标和所需的相关开发严谨性，并可供更高管理层用来签署根据所需的严格性开发产品所需的承诺。根据经验，ISO 26262第1版的缺点之一是，由于其故意缩小范围，施用者倾向于忽略与其他工程学科的联系以及由此产生的协同效应，这些协同效应可以使多个领域受益。示例范围限制包括：
- “危险”的定义仅限于电子系统故障行为（包括系统间交互）造成的潜在危害。其他危害，例如与更广泛的产品安全问题和特定技术实施固有的危害相关的危害，除非与电子系统故障直接相关，否则被视为不在范围之内。例如，在混合动力或电动汽车中与可充电储能系统相关的危险电能水平的情况下，电击和触电等危险超出了ISO 26262的范围，但在其他标准范围内，这些标准对物理保护和隔离电阻等事项提出了要求。但是，如果电子系统故障可能导致缓解措施的危险或失败，则属于ISO 26262的范围。
- “伤害”的定义仅限于人身伤害或健康损害;即使可能是由电子系统故障引起的，也不会考虑更广泛的损失或影响。
这导致了忽视或忽略与其他领域重要因素相互作用的趋势，例如机械故障模式。虽然通过避免标准故障模式和可靠性技术可以正确解决针对此类故障模式的产品设计，但应考虑此类故障模式对电子系统行为的影响，例如，考虑电子系统是否需要检测故障并向驾驶员发出警告或实施策略作为缓解措施的一部分。
在车辆中使用电子转向柱锁（ESCL）的案例可以证明这一点。ESCL是一种防盗条款，通常用于帮助满足FMVSS 114和联合国（UN）法规116的要求，以防止未经授权的车辆使用，并取代了无钥匙进入和启动车辆中的传统钥匙操作转向柱锁。
从功能安全的角度来看，危险分析将识别危险，例如在车辆行驶时不要求锁定方向盘，以及授权驾驶员进入车辆时未能解锁转向柱，这意味着车辆在转向锁定的情况下驶离停车位置。将确定安全目标以避免或减轻危害，并制定战略，并将其表述为实现这些安全目标的安全要求。
对于与避免不必要的与锁定相关的安全目标，典型的策略表现为检测可能导致危险的故障并确保系统处于“安全状态”（通常禁用ESCL功能）。对于避免在转向锁定的情况下驶离停车位置相关的安全目标，该策略通常还涉及检测转向柱是否未解锁等。未能解锁转向柱可能包括机械原因，虽然电子系统无法阻止这些根本原因，但可能需要检测它们是否已经发生并调用适当的操作，例如，警告驾驶员转向柱已锁定，他们应该尝试通过转动方向盘并抑制发动机启动来释放它，直到转向柱成功解锁。如果对功能安全采取非常狭隘的观点，则可能会忽略后一方面。
在制定ISO 26262第2版期间，负责工作组经常被要求考虑将信息安全纳入该标准。人们很快认识到，信息安全是一门足够复杂和独特的学科，其本身的标准已足够适用; 但是，至少它的某些方面与功能安全密切相关。因此，ISO 26262第2版包含以下与信息安全相关的四个要点（三个直接和一个间接）：
- 作为ISO 26262第2部分“功能安全管理”中建立安全文化的一部分，现在要求与功能安全相关的学科“建立和维护有效的沟通渠道”，信息安全作为具体示例。这一要求承认功能安全的某些方面与信息安全之间的密切关系。下面将对此进行更详细的探讨。
- 第 2 部分还包含一个新的信息性附件E，该附件为功能安全与信息安全之间的相互作用提供了额外的指导。这是从安全从业者的角度编写的，使他们能够了解从信息安全角度做出的决策如何影响电子系统的安全目标和其他安全属性的实现。
- 第6部分（软件级别的产品开发）认为，对于许多实现者来说，需要一个通用的软件开发过程，从许多来源（例如安全要求，功能要求）及其相关属性中收集需求。因此，通用的开发方法是可取的，甚至可以寻求共同的解决办法。
- 作为间接的观点，人们认识到，将故障电子系统设计为在故障原因中“故障沉默”的经典方法不适用于SAE J3016的3级及以上的自动驾驶功能，因为驾驶员可能无法立即（或根本无法）做出反应， 因此，可能需要一定程度的“可用性”，以便在发生故障时允许继续或替代操作，因此需要确保安全解决方案不会与可用性要求相冲突（这样做可能会成为拒绝服务攻击的载体）。
SOTIF（预期功能安全）作为“公开可用的规范”（ISO/PAS 21448：2019）已经发布，并将继续朝着完整标准发展，SOTIF方法最初源于在高级驾驶辅助系统（ADAS）和自动驾驶系统中，存在与预期功能相关的危险原因，并且通常与传感器系统的性能有关。例如，因为雷达传感器检测到躺在路面上的金属板而导致的自动紧急制动（AEB）的“误报”触发。对于一些从业者来说，这些不被认为是ISO 26262意义上的故障，需要不同的方法。此外，在考虑ADAS和自动驾驶时，存在未知且可能不安全的潜在场景和驾驶情况。
SOTIF文件中的部分方法是考虑如何最小化“未知和不安全”情况（也称为“极端情况”）的范围，同时承认该领域永远无法在测试中完全理解或涵盖这些极端情况。21448中特别重要的内容是表1，其改编内容转载如下，它承认仅考虑故障行为的经典功能安全方法只是可能导致系统显示不需要的和潜在的不安全行为的大约 10 个因素之一。请注意，表中包括了信息安全。
表1：不同ISO标准（改编自ISO/PAS 21448：2019）涉及的安全相关主题
| 来源 | 危险事件的原因 | 范围 |
| 系统 | E/E 系统故障（导致故障） | ISO 26262 series* |
| 性能限制或态势感知不足，有或没有合理可预见的滥用 | ISO/PAS 21448 | |
| 合理的可预见的错误操作、不正确的 HMI（例如，用户混淆、用户过载） | ISO/PAS 21448 ISO 26262 series* European statement of principles on HMI | |
| 系统技术造成的危害 | 产品特定标准 | |
| 系统干扰，例如连接问题 | 互操作性（包括 EMC/EMI，例如 ISO 11451 系列*和 ISO 11452 系列*） | |
| 外部 因素 | 利用车辆安全漏洞进行成功的（信息安全）攻击 | ISO/SAE 21434 |
| 主动基础设施或车对车通信、外部设备和云服务的影响 | ISO 20077 series* ISO 26262 series* | |
| 汽车周围环境的影响（其他用户、“被动”基础设施、环境条件：天气、EMI 等） | 互操作性（包括 EMC/EMI，例如 ISO 11451 系列*和 ISO 11452 系列*） |
考虑到功能安全和信息安全之间的一些具体交互点，可以确定以下良好实践领域： 危害分析和随后的安全要求推导应将成功的攻击视为危险的潜在原因。如果从信息安全角度进行的威胁分析确定了潜在的安全相关结果，则需要将其传达给安全分析活动，并适当考虑和调整。这确实意味着组织需要一种机制来进行这种沟通，特别是当不同的团队和不同的流程用于功能安全和信息安全时。 此外，在ISO/SAE 21434背景下进行的威胁分析和风险评估中，要求根据ISO 26262方法对威胁分析和风险评估（TARA）期间确定的安全相关影响进行分类。 与此相关，如前所述，从危害分析和风险评估得出的功能安全属性是安全目标及其相关的ASIL值。ASIL的一种解释是，它代表了一种“通用语言”，可以在供应链内的开发过程和产品设计中进行所需的严谨流。人们普遍认为，信息安全需要类似的方法;目前，ISO/SAE 21434中提出了“信息安全保证级别”（CAL）的概念，但由于需要获得应用经验，因此仅作为信息内容。ASIL 和 CAL 之间不一定有映射（即，高 ASIL 并不意味着高 CAL，反之亦然）。回到ESCL的例子，前面没有提到的另一个故障是在车辆停车时无法锁定转向柱。从ISO26262的角度来看，这种故障通常不会被视为危险，因为无法确定合理可预见的伤害（就对人的伤害而言），因此不会分配ASIL（或被视为“QM”）。但是，从信息安全的角度来看，禁用转向柱锁的成功攻击可能是恶意行为者窃取车辆策略的一部分，因此它很可能会分配一个 CAL。与ESCL危害相关的相对ASIL和CAL的比较可能如表2所示（请注意，ASIL和CAL值仅供参考）。
表2：与ESCL危害相关的相对ASIL和CAL的比较
| Hazard | ASIL | CAL (安全) | CAL (经济损失) | CAL(操作性) | CAL (隐私) |
| 无要求锁定 | 高 | 高 | 高 | 高 | 无 |
| 锁定失败 | 无 | 无 | 高 | 无 | 无 |
| 解锁失败 | 低 | 低 | 高 | 高 | 无 |
| 无要求解锁 | 无 | 低 | 高 | 无 | 无 |
从上表可以看出：
- 诸如CAL之类的属性可能包含针对不同的不利安全结果（例如，安全性、财务损失、操作限制或隐私丢失）的不同评分，因此，它可以被视为向量而不是单个值。
- 以这个特定系统为例，ASIL与CAL的安全方面之间存在很强的相关性，尽管并非所有系统都是如此。
- CAL的财务方面对于未能锁定的评级是“高”的，因为这可能与车辆被盗有关，即使从ISO 26262的角度来看，这种故障被认为与安全无关。
- CAL的财务和运营方面因解锁失败而“高”。未能解锁可能会使车主面临替代运输和维修的费用。它还代表了一种操作限制，虽然使所有者感到沮丧，但如果认为特定产品或一系列产品容易受到此类攻击，则可能会对制造商产生更广泛的影响。
- 最后一项意见还提出了一个问题，即是否从车辆使用者和产品的个别实例的角度处理影响，或者是否需要考虑对产品车队或制造商的影响。ISO/SAE 21434是从前者的角度编写的，但该标准的用户可以根据需要扩大影响范围。
必须考虑安全要求和安保要求之间的一致性和可能的冲突，例如，必须确保安全概念不是潜在安全漏洞的来源。例如，一种安全机制可以删除一种功能（可能导致性能降低甚至停止车辆），攻击者可能会利用该功能，其目标是停止车辆以威胁乘员或窃取车辆。相反，安全概念不应成为无法实现的安全要求的原因（例如，加密要求及其相关的处理时间可能与安全规范的时间敏感故障检测机制冲突;实时监控和事件响应机制可能与安全相关的可用性要求冲突）。
在从功能安全角度对系统架构进行规范、设计和实施时，必须明确并实现“独立性”和“不受干扰”的属性。在需要冗余实现的情况下，通常要求架构元素之间的“独立性”，因此可以应用 ASIL 分解。当安全相关的和非安全相关元素必须在同一环境中共存时，需要“不受干扰”，并且必须证明非安全相关元素的故障不会对安全相关元素产生不利影响。从安全角度来看，将需要类似的概念，例如演示与安全相关的组件和非安全相关的组件之间的“隔离”（或类似的属性）。作为另一个因素，可能需要与安全架构约束的重叠和相互作用。
请注意，在信息安全的上下文中，安全相关和非安全相关组件之间需要隔离（例如，软件组件Y和软件组件U之间）。从功能安全的角度来看，必须证明软件组件Y没有级联故障可能影响分配给软件组件U的安全要求; 但是，从信息安全角度来看，还必须证明软件组件U不会对软件组件Y产生不利的安全影响.还需要在具有不同保证级别的安全相关组件之间隔离，例如，在软件组件Y和软件组件W之间。
软件架构中不受干扰和独立性的示例。
一般而言，必须制定执行所需性能的安全机制和对策，以满足其所保护组件的最高完整性和保证性要求；因此，在上面的示例中，操作系统（OS）或基本软件层继承了 ASIL D的安全完整性要求和 CAL 4的信息安全保证要求。虽然某些属性可能一致（例如，与软件组件Y相比，软件组件W具有更高的安全完整性要求和信息安全保证要求，并且可能存在常见的解决方案，例如内存保护），但情况并非总是如此。
尽管上述主题具体涉及功能安全与信息安全之间的相互作用，但实现信息安全可能还需要与其他属性（如质量、可靠性和维修性）进行交互和权衡。最终，需要基于系统工程并使用行业商定的风险优先级方法（如 CAL）的方法。
912
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
