CN115408684A - 持久安全性配置监测 - Google Patents

Abstract

当发现软件和/或硬件系统的安全性漏洞时，考虑到现代嵌入式系统的复杂性，重新配置软件和/或硬件以解决安全性漏洞越来越困难。因此，提供一种在系统的多个生命周期阶段对定义可配置软件和/或硬件系统的持久配置记录进行持久安全性配置监测的计算机实现方法，包括在系统的第一生命周期阶段期间，根据自动化引擎的第一配置使用第一自动化引擎自动施行第一安全性任务，其中第一配置定义要由第一自动化引擎施行的目标动作，以及由第一自动化引擎可检测的触发目标动作的事件，使用第一自动化引擎检测事件，使用第一自动化引擎更新与第一生命周期阶段相关的持久配置记录的一部分，以及响应于事件的检测经由第一自动化引擎触发至少一个安全性任务。

Description

持久安全性配置监测

技术领域

本申请涉及一种用于在系统的多个生命周期阶段内对定义可配置软件和/或硬件系统的持久配置记录进行持久安全性配置监测的计算机实现的方法，以及相关联的系统、计算机可读介质和嵌入式软件和/或硬件系统。

背景技术

电子控制单元（ECU）是根据分阶段的过程开发的，经常在汽车工程中应用的“V-model”方法内构造。当发现软件和/或硬件系统（诸如机动车辆的电子控制单元ECU）的安全性漏洞时，考虑到现代嵌入式系统的复杂性，重新配置系统的软件和/或硬件以及时解决安全性漏洞变得越来越困难。

经常施行离散的安全性监测任务，并且针对规范的操作不符合性最终被报告回OEM、1级、2级或3级供应商以采取动作。然而，这样的安全性监测过程可以进一步改进。

发明内容

根据第一方面，提供了一种用于在系统的多个生命周期阶段内对定义可配置软件和/或硬件系统的持久配置记录进行持久安全性配置监测的计算机实现的方法。该方法包括：

- 在系统的第一生命周期阶段期间，根据自动化引擎的第一配置使用第一自动化引擎自动施行第一安全性任务，其中所述第一配置定义要由第一自动化引擎施行的目标动作（a），以及由第一自动化引擎可检测的触发目标动作的事件；

- 使用第一自动化引擎检测事件；

- 在检测到事件时，使用第一自动化引擎更新与第一生命周期阶段相关的持久配置记录的一部分；以及

- 响应于事件的检测，经由第一自动化引擎触发至少一个安全性任务。

效果是提供了高度自动化和高覆盖的网络安全性生命周期配置管理系统，使得在嵌入式软件和/或硬件系统的第一生命周期阶段中发生的自动安全性相关观察与可以在第二生命周期阶段中应用的自动安全性相关动作之间能够互连。生命周期开发阶段之间的自动互连意味着，当进行自动安全性相关观察时，诸如单元测试生成或代码重新编译之类的技术活动可以自动指定在其它生命周期阶段中发生。在开发过程的早期进行自动安全性相关观察的情况下，可以自动升级或重新配置该开发过程的后续生命周期阶段，以解决在开发过程的早期进行的安全性相关观察。

替代地，在硬件或软件系统开发过程的后期阶段，可能发生自动安全性相关观察的情况。在这种情况下，可以更新硬件或软件系统的永久配置记录，使得当生命周期针对硬件或软件系统重复时（例如，生命周期可以作为后续相关硬件或软件系统的技术设计模式完全重复），在开发过程的后期阶段发生的自动化安全性相关观察可以在设计过程的后续实例化的较早期阶段被计及。更进一步的，可以部分地重复设计过程（例如，可以重新运行软件实现生命周期阶段，以根据未改变的规范和开发框架为已知的硬件或软件系统生成软件更新，尽管可以使用自动化安全性相关观察（诸如错误报告或异常硬件信令观察）来自动生成要在重新实例化的实现阶段中应用的单元测试）。

因此，由微服务监测引擎施行的在第一生命周期阶段发生的自动化安全性相关观察可以在其它生命周期阶段被其它微服务应用引擎自动计及，这意味着在实现对它们的解决方案之前观察不会丢失或被忽略。因此，根据这样的持久配置记录设计的硬件和软件系统将更耐安全性攻击，并且更快地被重新配置以抵抗安全性攻击。持久的配置记录可以容易地被机器学习算法读取，该算法被训练来标识被定义为若干生命周期阶段的结果的系统的技术实现中的模式。

微服务提供的可用性和可扩展性意味着，如果例如在操作阶段发生大量的自动安全性观察（例如，发现了影响诸如CAN网关之类的核心电子控制单元的新漏洞利用（exploit）），则在与新漏洞利用相关的设计过程的未来实例化中的设计或规范阶段中引发的类似大量的持久微服务可以在没有用户干预的情况下自动生成。

因此，持久配置记录基于触发这些任务的特定事件或条件，对要在未来的另一个安全性生命周期阶段或未来的安全性生命周期阶段的后续实例化中施行的任务进行编码。持久配置记录由对应的自动化引擎以完全自动化的方式处理，使得任务和一个生命周期阶段能够以完全自动化的方式取决于不同生命周期阶段中的结果事件或其它条件来施行。

根据第二方面，提供了一种包括至少一个计算装置的计算机系统，所述计算装置包括数据存储器、输入输出接口和处理器，其中所述计算机系统被配置为施行根据第一方面或其实施例的方法。

根据第三方面，提供了一种包括计算机可读指令的计算机可读介质或信号，当由计算机处理器执行时，所述计算机可读指令执行根据第一方面或其实施例的方法。

根据第四方面，提供了一种嵌入式软件和/或硬件系统，其根据根据第一方面或其实施例生成的永久配置记录来配置，其中所述嵌入式软件和/或硬件系统可选地是用于控制车辆的电子控制单元。

在以下应用中，“生命周期阶段”是一个离散的时间段，在此期间，硬件和/或软件系统设计从高级别的概念朝向技术上成熟发展并安全性地释放给客户。例如，在规范阶段中，可以进行系统需求分析，以确定最终产品的特征集。在设计阶段中，在规范阶段发现的系统需求使得能够做出关于最终设计的架构和模块设计的决策。后续实现阶段使得电路的实际设计和计算机代码的实现能够将先前的系统规范和设计传送到功能系统中。单元测试可以应用于实现阶段，以确保功能系统的每个模块按预期施行。当然，规范或设计阶段的改变也暗示可能需要在实现阶段编写新的单元测试。单元测试可能由人类分析师编写。然而，单元测试可以基于软件和/或硬件环境自动配置（填充）。至少，单元测试的空“存根”可以基于自动检测到的需求自动填充。如果自动生成的单元测试存根没有完成，使得它们向自动编译器返回“通过”值，则代码库的最终编译可能失败。因此，例如，确保满足这些要求的设计和规范的集成、系统和接受测试测试方面可以被自动化，以确保不符合的软件或硬件配置不会达到生产。

其中产品处于正常使用的操作阶段发生，并且设计没有改变。然而，系统的性能可以针对规范和设计来测量。更进一步的，系统在操作阶段的异常技术行为是一个重要的技术线索，即需要引入附加的单元测试，并且可能需要对规范和设计进行更基本的改变。

在以下应用中，术语“持久配置记录”指的是包含设计过程和最终硬件和/或软件系统的定义的一个或多个数据结构。在早期阶段，持久配置记录可以包括高级别配置声明，诸如“系统应耐SPECTRE攻击”。在后面的阶段，持久配置记录可以包括定义硬件和/或软件系统的设计的数据记录的高度异质的集合，其在自动确定系统的安全性可能是有用的。例如，永久配置记录可以包括C、C++、汇编、Java、MISRA C、Autosar C++的软件代码、诸如Verilog或VHDL的硬件定义语言、电路示意图以及诸如此类。

永久配置记录包含硬件和/或软件电子系统的完整设计并不重要，尽管永久配置记录中包括的设计方面越多，可以提供的设计覆盖就越大。因此，当检测到新的安全性相关事件时（例如在操作阶段中检测到新的软件漏洞利用），这被存储在永久配置记录中。然后，例如有可能在从新软件漏洞利用向后的关键路径上自动回溯到先前的生命周期阶段，以在实现阶段中自动定义新的单元测试。

永久配置记录可以包含定义电子控制单元或软件的使用环境的条目，因为这些条目也影响软件和硬件产品的安全性。例如，永久配置记录可以定义使用软件和/或硬件的车辆型号、车辆活动的时间、连接到ECU的其它类型的软件和硬件以及诸如此类。

尽管本说明书的许多方面涉及汽车开发和用于汽车的ECU，但是本说明书并不限于此。本文中讨论的技术可以应用于宽范围的软件、硬件以及具有复杂配置的混合产品和服务，该复杂配置可以在至少两个生命周期阶段内演进。

在以下说明书中，“安全性任务”是可以提高硬件和/或软件系统的安全性或减少攻击面的操作。

附图说明

在各图中描绘了示例性实施例，这些实施例不应被解释为限制权利要求，并且在下面更详细地解释。

图1示意性地图示了根据第一方面的方法。

图2示意性地图示了包括根据第二方面的系统的持久生命周期开发环境。

图3示意性地图示了在操作阶段期间检测车辆中异常ECU状态的方法。

图4示意性地图示了用于持续安全性配置监测的微服务架构。

图5示意性地图示了响应于安全性事件的检测，在不同时间点包括持久配置记录的相同数据结构的两个版本。

图6示意性地图示了基于持久安全性配置记录的生命周期和渐进自动适应的多个实例化。

具体实施方式

安全性事件是对可能对最终产品硬件或软件系统的安全性有害的事件或漏洞利用的检测。“事件”的性质取决于其中漏洞利用被针对的系统部分。诸如提供例如车辆环境的电子控制单元之类的复杂的嵌入式系统呈现各种各样的可能“事件”。因此,“事件”的发生与在它的环境中操作的软件和/或硬件系统设计提供的攻击服务的类型有关。

由于安全性事件激增的异质性和速度，维护硬件和/或软件系统的技术配置变得越来越困难。

可能与ECU相关的安全性事件的示例许多且变化。为接收IEEE 802.11 WiFi（TM）、V2X传输和蜂窝传输而无线连接的ECU可能容易被窃听、拒绝服务或欺骗。ECU的物理输入可以是诸如USB、以太网、CAN或MOST之类的端口。更进一步的，系统用户可能将受感染的硬件设备（诸如受损的智能电话）插入ECU的USB端口中，从而使得第三方设备中使用的软件配置或应用选择与系统安全性相关。

诸如CAN之类的内部车辆通信可能将许多不同的电子控制单元连接在一起，使它们更容易被窃听或拒绝服务，并增加了可能的安全性事件的数量。通过监测电子控制单元之间CAN通信的异常模式或突发，可以检测到异常安全性事件。诸如相机和雷达之类的许多传感器可能提供攻击媒介。例如，由电子控制单元执行的软件可能受损。

安全性事件也可以与特定的系统硬件和软件无关，但是可以是硬件和/或软件系统的操作环境的一部分。例如，大量新的漏洞利用正在被发现，并不断在互联网数据库中发布。攻击装备的价值可能改变，因此使得特定的攻击或多或少可能取决于攻击装备的成本。如果在硬件和/或软件系统的更广泛的操作环境中检测到的漏洞利用与硬件和/或软件系统相关，则应该对其进行评分，并且如果判断为关键，则现有的硬件和/或软件系统应该经受软件修补，以在短期内解决关键故障，并且未来的设计生命周期阶段应该在设计电子控制单元的新迭代时设计出长期的关键故障。安全性攻击的现代激增和跨学科性质对有效管理其在不同生命周期阶段的风险提出了挑战。

本申请中考虑的示例是高度自动化车辆中的域ECU的示例。这样的ECU是一个复杂且互连的硬件和软件系统。然而，有技术的读者将领会，该技术可以无限制地应用于软件代码开发、硬件开发或两者的混合。

图1示意性地图示了根据第一方面的方法。

根据第一方面，提供了一种用于在系统的多个生命周期阶段对定义可配置软件和/或硬件系统的持久配置记录进行持久安全性配置监测的计算机实现的方法，包括：

- 在系统的第一生命周期阶段期间，根据自动化引擎的第一配置（C1）使用第一自动化引擎（EP1）自动施行第一安全性任务，其中所述第一配置定义要由第一自动化引擎（EP1）施行的目标动作（a），以及由第一自动化引擎（EP1）可检测的触发目标动作（a）的事件；

- 使用第一自动化引擎（EP1）检测事件；和

- 在检测到事件时，使用第一自动化引擎（EP1）更新与第一生命周期阶段相关的持久配置记录的一部分；以及

- 响应于事件的检测，经由第一自动化引擎（EP1）触发至少一个安全性任务。

图2示意性地图示了包括根据第二方面的系统20的持久生命周期开发环境。在ECU22生命周期的设计和实现阶段中，系统20的持久生命周期开发环境可以作为软件和硬件配置和开发的安全性“试验台”来施行。例如，在ECU 22生命周期的操作阶段中，系统20可以施行为操作监测器来检查根据永久配置记录配置的ECU 22的反应，该永久配置记录可以保证不受损于某些新的漏洞利用。

系统20可以包括原型或最终的电子控制单元ECU 22，其包括数据存储器26、输入输出接口24和处理器28。输入-输出接口24可以例如包括CAN、MOST、以太网、802.11p GSM或V2X通信接口，从而向ECU 22呈现攻击面，并且扩展到经由通信接口连接到ECU的其它组件。例如，ECU 22可以经由输入-输出接口24连接到“裸机”组件和传感器，诸如制动系统、雷达系统或汽车锁定系统以及诸如此类的组件（未图示）。

ECU 22的数据存储器26具有非易失性和易失性组件。例如，易失性组件是RAM（随机存取存储器或高速缓存），用于支持处理器28执行程序。例如，非易失性组件使得能够长期存储ECU的操作软件模块。例如，作为ECU 22配置的操作阶段中自动异常监测的结果，ECU22的操作软件模块可以根据作为安全性任务自动触发的实现阶段的新实例化中生成的软件更新来部分或全部更新。

ECU 22的处理器28被配置为从ECU 22的数据存储器26加载ECU 22的操作软件模块，并且经由ECU 22的输入输出接口24与连接到ECU 22的外部设备通信。

系统20可以包括数据网络30。数据网络30连接到持久配置控制接口32（其可以是一个或多个个人计算机、数字平板以及诸如此类），持久配置控制接口32可通信地耦合到持久配置服务器34。持久配置服务器34保存一个或多个持久配置记录，这些记录定义了存储在例如ECU 22的数据存储器22中的可配置软件和/或ECU 22耦合到其的硬件架构。持久配置服务器34可以包括ECU 22的参考实例化（或设计），以及以一系列终端使用环境为目标的参考实例化的变体（例如，可能存在用于不同车辆设计的参考实例化的变体，或者不同软件更新的配置的快照）。后续在图5中图示了可以保存持久配置记录的示例数据结构。

因此，例如，在规范、设计或实现生命周期阶段中，ECU 22软件和/或硬件的不同配置可以从永久配置服务器上传，以快速测试新兴的威胁。

系统20进一步包括到至少一个威胁数据库36的数据连接。例如，威胁数据库36可以是软件漏洞、公司和安全性公司的安全性建议以及诸如此类的数据库。可以使用机器学习服务器（未示出）自动填充威胁数据库36，该机器学习服务器被配置为自动爬取研究组的网站和软件漏洞数据库。

系统20进一步包括“硬件在环”试验台38。“硬件在环”试验台使得在操作生命周期阶段将连接到电子控制单元22的硬件（或“裸机”）组件能够通信地耦合到电子控制单元22。例如，如果链接到车辆视觉子系统和相关联的ECU的攻击媒介是一个问题，则环路试验台38中的硬件可以包括车辆相机和LIDAR的集合，用于再现可能经由车辆视觉子系统引入或注入的安全性漏洞。

系统20进一步包括多个微服务主机44、45、46、48。在实施例中，为每个生命周期阶段提供微服务主机。在所图示的示例中，系统20包括规范阶段微服务主机44、设计阶段微服务主机45、实现阶段微服务主机46和操作阶段微服务主机48。

每个微服务主机44、45、46、48被配置为操作后续要描述的自动化引擎EP1-EP4。自动化引擎的功能是在每个生命周期阶段应用配置Ci，在该示例中，该配置Ci可以包括声明式安全性规范，该声明式安全性规范由目标动作（a）的声明、将触发目标动作的一个或多个事件或条件的定义、以及关于可以如何执行目标动作的信息组成。例如，该信息可以是到对应微服务的链接，具有用于调用微服务的特定参数。

主机44、45、46、48上托管的每个微服务可以例如由系统20中的其它组件通过RESTful API来访问。每个微服务以这样的方式定义和实现，即在自动检测到反映ECU 22的配置和使用的过去、现在和未来生命周期阶段中发生的事件时，可以以全自动化的方式消费该微服务。更进一步的，微服务主机44、45、46、48上托管的每个微服务可以由提供连续安全性保证服务的自动化或人工安全性分析师来访问。

主机44、45、46、48上托管的至少一个微服务可以例如经由网络30与其它主机之一的通信，直接向主机44、45、46、48上托管的另一个微服务传送表示在第一生命周期阶段中存在安全性漏洞的事件的检测。替代地或附加地，当主机44、45、46、48之一上托管的微服务在第一生命周期阶段自动检测到漏洞的存在时，永久配置记录70a/70b。在ECU 22的操作生命周期阶段中，由操作生命周期阶段微服务主机48托管的至少一个微服务可以经由监测威胁数据库36来检测由ECU 22操作的软件模块的新的安全性漏洞利用。响应于此，由操作生命周期阶段微服务主机48托管的至少一个微服务向永久配置记录70a 70b写入标识检测到的新安全性漏洞利用22的新条目。由另一个生命周期阶段微服务主机托管的至少一个其它微服务可以读取写入永久配置记录70a 70b的新条目。这可以触发至少一个其它微服务来施行至少一个安全性任务。

例如，在自动检测到与ECU 22软件相关的威胁数据库36中的威胁的情况下，操作阶段微服务可以将已经发生给定类型的安全性事件写入永久配置记录70a的操作阶段记录72d。在与ECU 22相关的生命周期开发过程的后续未来实例化时（这可以是对现有ECU 22的软件更新的开发，或者使用现有ECU 22设计作为参考为未来ECU设计开发全新的软件集合），规范生命周期阶段微服务、设计生命周期阶段微服务和/或实现生命周期阶段微服务可以读取写入永久配置记录70a的操作阶段记录72d中的事件，并且作为响应形成至少一个安全性任务。

例如，设计阶段微服务可以自动在持久配置记录70a的操作阶段记录72d中读取在威胁数据库36中检测到新威胁。作为响应，设计阶段微服务可以自动扫描相关ECU 22设计的软件模块列表，并声明设计不符合受新威胁影响的软件模块。另一微服务可以搜索不受新威胁影响的替代软件模块。如果发现新的模块，则它们可以替换受影响的模块。

系统20进一步包括至少一个自动化生命周期配置监测服务器42。自动化生命周期配置监测器42读取存储在持久配置服务器34中的一个或多个持久配置记录70a 70b。自动化生命周期配置监测服务器42与系统30的其它元件通信耦合，并且特别是主机44、45、46、48上托管的微服务。自动化生命周期配置监测服务器42可以例如被配置为生成数据分析和/或对微服务的发现和/或对持久配置记录的配置施行无监督的机器学习。作为示例，它们可以产生提供给其它微服务和/或人类安全性分析师或操作员的结果。

在一示例中，自动化生命周期配置监测服务器42被配置为监测多个生命周期阶段，并作为例如ECU 22的整个网络安全性生命周期及其使用环境和历史的“数字孪生”来施行。以这种方式，可以跨多个生命周期发展阶段跟踪与特定ECU 22配置的安全性不符合性相关的更复杂模式在操作环境中的演变，该操作环境部分地以在威胁服务器36中检测到的威胁为特征。

在一示例中，系统20进一步包括到操作安全性监测器40的网关。操作安全性监测器40可以是车辆安全性信息事故和事件管理系统VSEIM 52，在图3中图示并后续讨论。操作安全性监测器40可以监测一个或多个运行中的车辆或在其操作生命周期阶段操作的系统。例如，在操作生命周期阶段微服务主机48中操作的微服务可以被配置为检测由事件管理系统VSEIM 52经由操作安全性监测器40报告的真实世界系统中的异常信号。在检测到真实世界系统中的异常信号时，操作阶段微服务主机48将更新持久配置记录70a 70b的操作记录72d，从而触发至少一个其它生命周期微服务来施行动作。例如，在操作阶段期间，在执行软件模块的给定版本的ECU 22和另一ECU之间的异常数据传送的检测触发操作中的记录72d。在生命周期的后续实例化的设计生命周期阶段中，ECU 22中的软件模块的给定版本被自动回复到在操作阶段中没有显示异常数据传送的先前迭代。操作者被通知应该采取动作来调查异常数据传送，并且同时，不显示异常行为的软件模块被替换。

图3示意性地图示了用于在操作阶段期间检测系统中、特别是车辆中的异常ECU状态的方法。

车辆系统50包括第一车辆54和第二车辆56。每个车辆包括多个ECU。更进一步的，每个车辆包括入侵检测传感器IDS。每个车辆被配置为将来自多个ECU和IDS的看门狗信号传送到车辆安全性事故和事件管理系统VSIEM 52。VSIEM 52是可以在操作阶段微服务主机48上执行的微服务的示例。看门狗信号可以表示一个或多个ECU的内部状态。看门狗信号可以表示一个或多个ECU之间的通信。看门狗信号可以包括在一个或多个ECU中执行的软件模块的数字签名。看门狗信号可以被定义为检测一个或多个车辆中发生的目标动作（a），并将其报告给VSIEM 52。

作为示例，车辆54和/或56中的IDS模块可以向VSIEM 52报告以下情况的发生，或者可以报告看门狗信号，使得VSIEM能够诊断：由至少一个ECU检测到的电气损坏、由一个或多个ECU检测到的未签名固件更新的安装、到CAN、MOST或以太网网络的内部车辆通信端口的异常连接、与内部车辆传感器相关联的篡改警告、在车辆内部检测到的数据存储完整性破坏，诸如操纵或复制存储在一个或多个ECU的存储器中的数据、来自与车辆相关联的GNSS传感器的位置信息、车辆的驾驶特性，诸如能量使用、制动器的致动、车轮速度、信息娱乐ECU中的任意代码执行、车辆的1个ECU和另一个ECU之间的服务拒绝以及许多其它漏洞。

图4示意性地图示了用于持续安全性配置监测的微服务架构60。

在一实施例中，该方法包括：

- 建立托管至少一个微服务的面向服务的架构平台，所述至少一个微服务通信地耦合到第一和/或第二自动化引擎；

- 使用所述至少一个微服务施行第一和/或第二安全性任务。

在该示例中，微服务架构60基于在三个对应的生命周期阶段62a、b、c中应用的三个自动化引擎EP1-3。例如，第一自动化引擎EP1协调在规范生命周期阶段执行的微服务。第二自动化引擎EP2协调在实现生命周期阶段执行的微服务。第三自动化引擎EP3协调在操作阶段执行的微服务。当然，技术人员将领会，根据所提供的自动化引擎的对应数量，可以跟踪更多或更少数量的生命周期阶段。

自动化引擎EP1协调至少一个微服务S1。所述至少一个微服务S1实现在给定生命周期阶段覆盖产品网络安全性生命周期需求所需的一个或多个单独的安全性任务。在一示例中，微服务可以链接到环路项目38中的硬件，使得在软件中发现的漏洞可以在相关硬件上被重新测试。

在一实施例中，该方法包括：

- 将第二自动化引擎耦合到被配置为复制系统的一个或多个硬件组件的硬件在环试验台；和

- 使用硬件在环试验台施行单元测试。

自动化引擎EP1可以链接到保存微服务S1的所有必要值的相关联数据存储D1。换句话说，相关联的数据存储D1充当这个特定微服务的持久存储。更进一步的，数据库D1可以提供短期或长期的数据存储。在一示例中，自动化引擎EP1可以检测对应于目标动作的事件。自动化引擎EP1在检测到事件时，更新持久的配置记录。这使得能够从第一生命周期阶段到一个或多个其它生命周期阶段实现过程间通信64a、b、c。

生命周期阶段EP1、EP2和EP3之间的过程间通信转发可能暗示例如在自动化引擎EP1决定更改设计规范，该设计规范被及时转发到在设计阶段中操作的自动化引擎EP2，该自动化引擎EP2基于更改的设计规范来替换软件和/或硬件模块。然后，由自动化引擎EP2提供的更改的软件和/或硬件设计可以被传送给在实现阶段中操作的自动化引擎EP3。EP3自动化引擎中的微服务可以被配置为基于在规范生命周期阶段中授权并由自动化引擎EP1捕获的改变的软件和/或硬件配置来重新生成单元测试。

如后续将描述的，在较晚的生命周期阶段中发生的事件还可能确定应用于开发过程的后续实例化的较早生命周期阶段的动作。

尽管图4图示了每个自动化引擎EP1-3仅链接到安全性生命周期中的直接前任或直接后续阶段，但是可以链接到安全性生命周期中的任何其它前任或后续阶段。这允许在与当前生命周期阶段不同的生命周期阶段触发安全性动作。例如，不同阶段之间的相互链接促进规则的实现，诸如“如果新的漏洞变得已知（例如，在MVD数据库中发布），则在开发团队问题跟踪系统中创建一个问题，以添加单元测试来检查该漏洞是否存在于被测试的产品或服务中”。

设计当前存在于哪个生命周期阶段的确定可以由人类设计配置管理器做出（例如，通过在永久配置记录中设置多个标志之一）。替代地，可以自动确定该设计当前存在于哪个生命周期阶段。例如，如果在实现阶段结束时单元测试全部自动通过，则那么实现阶段自动化引擎可以将此检测为事件，并且发信号通知代码和硬件设计已经通过测试并且被认为处于操作阶段。

更进一步的，自动化引擎EP1-EP3可以连接到人工智能或机器学习监测器66，以使得能够分析不同生命周期阶段中发生的事件之间的模式。

在一实施例中，至少一个安全性任务包括用第一和第二条目更新定义系统的持久配置记录的一部分，其中第一条目声明检测到事件，并且其中第二条目是记录检测到事件的生命周期阶段的生命周期阶段标识符，从而使得能够将事件的发生从第一生命周期阶段传送到第二生命周期阶段。

因此，第一条目可以是定义检测到的事件类型的语义元素，可选地具有时间和/或位置标签。可选地，例如，可以提供定义ECU 22或系统的状态的条目，其中ECU 22或系统包括在操作阶段中。生命周期阶段标识符可以例如通过数字、代码、标志或其它数据元素向一个或多个微服务指示已经在例如规范、设计、操作或实现阶段中检测到事件。

在一实施例中，该方法包括：

- 在系统的第二生命周期阶段期间，使用第二自动化引擎（EP2）读取持久配置记录的与系统的第二生命周期阶段相关的部分中的条目；

- 将持久配置记录的读取部分中声明检测到事件的条目与由第二自动化引擎（EP2）的第二配置定义的第二目标动作进行比较；以及

- 基于比较的结果，使用第二自动化引擎（EP2）实例化要由第二自动化引擎施行的第二安全性任务和/或由第二自动化引擎（EP2）控制的进一步处理操作。

图5示意性地图示了响应于安全性事件的检测，在不同时间点包括持久配置记录的相同数据结构的两个版本的示例。

在T=0时，永久配置记录70a的初始版本包括规范生命周期阶段记录72a、设计生命周期阶段记录72b、以及实现生命周期阶段记录72c和操作生命周期阶段记录72d。“事件1”已经在操作阶段中被检测到，例如通过监测来自一个或多个车辆54的信号的VSIEM 52。因此，由在操作生命周期阶段执行的自动化引擎操作的微服务已经向操作生命周期记录72d写入了已经检测到事件的更新。

在T=1时，持久配置记录72b的迭代版本图示了与规范生命周期阶段相关联的另外的自动化引擎在实现阶段中检测到“事件1”的存在时已经触发了安全性任务。因此，下一次迭代ECU 22的生命周期时（例如，作为软件更新过程的一部分），在操作阶段中自动检测和记录的异常可以在修订规范时被计及。

包括持久配置记录的数据结构可以以一系列不同的方式实现。数据结构可以包括在单个数据库中，或者单独的生命周期阶段记录70a-70d和72a-72d可以是指向其它数据库、文件或数据存储的指针。存储在每个单独的生命周期阶段记录70a-70d和72a-72d中的数据的性质可能是高度异质的。例如，规范生命周期阶段记录72a可以包含一个或多个高级别声明性陈述，如将在诸如“ECU 22应该耐SPECTRE攻击”之类的规范中找到的。设计生命周期阶段记录可以包括高级别系统架构定义、设计决策的细节，诸如已经选择了哪个处理器和哪些软件配置来实现符合规范的系统。实现生命周期阶段记录可以包括与ECU 22的实现相关的代码和/或HDL的记录。更进一步的，实现生命周期阶段记录可以包括对给定ECU 22设计迭代施行的自动化单元测试的结果。操作生命周期阶段记录可以包括ECU 22使用的日志。操作生命周期阶段记录可以包括ECU 22通信连接的日志。操作生命周期阶段记录可以包括ECU 22的意外通信不符合性的日志。操作生命周期阶段记录可以包括由本说明书中别处描述的车辆安全性信息事故和事件管理系统VSEIM 52生成的日志。

在一实施例中，第一生命周期阶段在第二生命周期阶段已经开始之前完成，使得持久配置记录的更新部分将事件的发生传送到未来的生命周期阶段中。

在一实施例中，第二生命周期阶段在系统的多个生命周期阶段的后续实例化的第一生命周期阶段已经开始之前完成。

根据面向服务的架构，自动化引擎EP1-3的应用的实际的、非限制性的示例现在在持久安全性自动化的上下文中讨论，该持久安全性自动化跨越我们的产品安全性生命周期的至少两个生命周期阶段。在非限制性示例中，持久安全性自动化可以跨越整个安全性生命周期。

ECU的示例开发过程可以包括四个阶段。规范阶段（SPEC）使得系统需求分析练习能够进行，以确定最终产品的特征集。在规范阶段中，从安全性角度来看，主要任务之一是威胁和风险分析，其中，对于ECU的每个组件，威胁或攻击树被填充。攻击树包括一个根节点（表示成功的漏洞利用）和一个或多个子节点（表示为了使安全性攻击成功必须在硬件或软件中发生的安全性事件）。

设计生命周期阶段的一个示例是这样一个阶段，在该阶段中，可能导致安全性漏洞的示例安全性任务或确保存在特定的技术和构建块以用于防止某些攻击。例如，在设计阶段中，特定的架构决策或设计模式可能被自动检测为易受“面向返回的编程”漏洞的攻击。作为响应，安全性任务可能要自动进入永久配置记录70b的设计阶段记录72b，诸如地址空间布局随机化（ASLR）之类的技术应该被包括在实现阶段中。

实现生命周期阶段任务的一个示例是自动化安全性测试的生成和施行，以测试软件以及它是否包含导致安全性漏洞的错误。更进一步的，可以在测试软件存在的情况下施行硬件在环测试，以获得更真实的测试环境。

操作生命周期阶段任务的一个示例是监测作为规范、设计和实现生命周期阶段的结果而实现的系统。例如，在汽车应用中，如图3中所图示的，车辆安全性事故和事件管理系统（VSIEM）可以监测至少一个ECU。替代地或此外，在车辆监测解决方案中，比如ETAS的CycurIDS（TM）/ESCRYPT系统，比如ARGUS车载网络保护或ARILOU Sentinel-CAN系统，可以标识汽车网络中的信令模式，这可以检测汽车入侵检测状态。更进一步的，操作生命周期阶段可能要获得关于其中操作所实现的ECU的改变的安全性环境的信息。例如，专业的漏洞数据库、新发布的漏洞领域的学术论文、从“暗网”中的论坛获得的情报、ECU组件的安全性组件制造商。所获得的信息可以与包括特定ECU版本或车辆的材料清单或软件组件列表进行比较。如果威胁度量上升到某个级别以上，则操作生命周期阶段任务可以自动生成对设计阶段装饰阶段的新实例化的要求（例如，生成软件更新）。

在第一个示例中，在操作生命周期阶段，这种新类型的攻击被检测到，诸如在漏洞数据库中发布了SPECTRE或MELTDOWN攻击。自动化引擎可以检测新攻击的存在，并通过检查在规范生命周期阶段中定义的ECU 22的攻击树，对其对根据设计规范实现的ECU 22的影响进行分类。如果规范阶段自动化引擎基于新漏洞利用与ECU 22的攻击树的比较（例如，通过词汇分析）检测到ECU 22可能易受攻击，则可以向人类操作员发布安全性警报。更进一步的，自动化引擎可以向负责设计生命周期阶段和实现生命周期阶段的其它自动化引擎发信号，通知应该找到替代设计和实现，直到漏洞被解决为止。

在第二个示例中，操作阶段生命周期引擎可以询问漏洞数据库36，并标识与ECU相关的某个攻击装备项目的价格已经上涨或下跌。因此，对应于持久配置记录的规范部分中的攻击树的叶子的数值可以被更新。因此，负责规范生命周期阶段的自动化引擎被配置为重新运行威胁和风险分析。因此，基于现场观察，重新评估ECU 22安全性状态。

在第三个示例中，在设计生命周期阶段操作的自动化引擎可以检测ECU 22的设计配置的改变。例如，这可以由更新到代码库的新C++、Verilog或VHDL文件来触发。更进一步的，在模型（例如，基于ASCET）生成的代码库中，模型中的改变可能是触发事件。设计生命周期阶段自动化引擎经由持久配置记录向实现阶段自动化引擎传送设计中的改变。在实现阶段应用的安全性测试可以在设计改变的环境中重新运行。

在第三个示例中，如果新的漏洞出现在公共NBD漏洞数据库中，则实施阶段自动化引擎被配置为检查软件BOM在ECU 22中实现的第三方软件组件（包括开源软件）的版本，并且如果对应的版本（诸如包含已知漏洞的版本）是如实现的软件BOM的一部分，则自动创建错误报告。替代地，实现阶段自动化引擎可以在漏洞数据库中出现漏洞时自动创建单元测试的存根。单元测试的存根被配置为在实现阶段期间使支票失败，并且因此暂停ECU软件的构建过程，直到实现阶段中的开发者已经解决了所描述的漏洞为止。所生成的存根可以被扩展成针对该漏洞的完整安全性测试，或者如果认为该漏洞是不相关的，则可以将其删除。

更进一步的，如果在安全性测试期间在实现阶段中发现了错误，或者在设计阶段中发现了导致安全性漏洞的架构缺陷，则系统可以在操作阶段期间自动传递信息，并将其添加到必须监测的行为（例如，通过VSIEM 52）。

在一实施例中，第一生命周期阶段是操作阶段（OPRS），并且第二生命周期阶段是多个生命周期阶段的后续实例化的规范阶段（SPEC），并且：

-在操作阶段中，第一自动化引擎（EP1）被配置为针对新的安全性漏洞的发布监测威胁数据库，并且用定义新的安全性漏洞的新记录来更新与系统的规范阶段（SPEC）相关的持久配置记录的一部分；和

- 在多个生命周期阶段的后续实例化的规范阶段（SPEC）中，检查包括在与规范阶段（SPEC）相关的持久配置记录的部分中的系统的攻击树。

在一实施例中，第一生命周期阶段是操作阶段（OPRS），以及第二生命周期阶段是多个生命周期阶段的后续实例化的规范阶段（SPEC），并且：

- 在操作阶段中，使用第一自动化引擎观察，以获得关于与系统相关的威胁环境的定性信息；

- 在操作阶段中，使用第一自动化引擎更新与规范阶段相关联的永久配置记录的一部分；以及

- 在多个生命周期阶段的后续实例化的规范阶段（SPEC）中，使用第二自动化引擎来调整在与规范阶段相关联的持久配置记录的部分中定义的系统或系统组件的威胁评估分数。

图6示意性地图示了基于持久安全性配置记录的生命周期和渐进自动适应的多个实例化。

轨迹80图示了ECU 22的初始生命周期开发过程，迭代通过规范、设计、实现和操作生命周期阶段，并且在每个生命周期阶段由四个自动化引擎之一监测。在操作生命周期阶段OPRS1期间，监测车辆的VSIEM检测到CAN总线异常，作为由操作生命周期阶段自动化引擎可检测的事件，并且自动化引擎施行将CAN总线异常的发生以及异常的细节写入存储在服务器34中的永久配置记录的目标动作。该任务可以由操作生命周期阶段微服务主机48中的微服务来施行。

轨迹82图示了ECU 22的另一版本（或更新版本）的后续“从头开始”生命周期开发过程，其中重新考虑了ECU 22的整个设计。这可以被认为是初始生命周期开发过程的未来实例化，该过程意图使用来自轨道80的初始ECU 22生命周期的技术反馈来生成更新的ECU22设计。特别地，在规范生命周期阶段SPEC2，规范生命周期阶段微服务主机44被配置为在永久配置记录中检测在先前的操作生命周期阶段OPRS1中检测到的CAN总线异常的发生。这触发规范生命周期阶段微服务主机44使用微服务来施行安全性任务，该微服务使用异常的细节来询问威胁数据库36。作为响应，威胁数据库36可以建议自动更改SPEC2中的规范以要求禁用特定CAN端口的解决方案。随着轨迹82中所图示的生命周期移动到设计生命周期阶段DESG2，可以自动调整设计的硬件和/或软件配置，以关闭在SPEC2阶段中自动指定的特定CAN端口。

实现阶段微服务主机46运行微服务来自动比较DESG1中的先前实例化的设计与从生命周期阶段DESG2得到的设计。实现阶段微服务主机46可以例如操作验证覆盖比较微服务，注意DESG1输出的设计是根据IMPL1中的预定义覆盖来验证的，但是由于SPEC2中的规范改变造成的DESG2中的设计改变，DESG2设计当前没有被最优地验证。在一个选项中，IMPL2中的微服务可以检测DESG2设计与DESG1设计相比的次优验证状态，并且在构成生命周期阶段IMPL2中的设计的单元测试的软件组件集中自动生成存根文件TEST1。可选地，存根文件可以被预设为在编译IMPL2中的软件组件集时引起编译器失败。此效果是提供一种自动防故障装置（fail-safe），使得当设计作为SPEC2中的改变的结果而改变时，需要在IMPL2中重新验证的设计部分被重新验证。

在轨迹82中，更新的ECU 22移动到操作生命周期阶段OPRS2，其中，例如操作生命周期微服务主机48自动引发并托管监测微服务，以确保规范改变以关闭与异常CAN通信相关联的CAN总线端口，如在生命周期阶段IMPL2中实现的，已经具有移除异常通信的效果。

在轨迹82中，给出了ECU 22的总体生命周期重新设计的完全实例化没有发生的情形的示例。代替地，来自先前实例化DESG2的先前设计以替代方式实现（可能使用不同的软件或硬件BOM），因此在实现阶段IMPL3的实例化中需要附加的测试TEST2，从而导致OPRS3。这是一个示例，其中公开的技术帮助更新ECU 22设计的子模块，而不是需要完全的重新设计。

在一实施例中，第一生命周期阶段是设计阶段（DSGN），以及第二生命周期阶段是实现阶段（IMPL），并且该方法进一步包括：

- 在设计阶段中，使用第一自动化引擎检测在定义系统设计的永久配置记录的一部分中表达的系统设计的改变；

- 在设计阶段中，使用第一自动化引擎（EP1）更新与实现阶段相关的持久配置记录的一部分，使得覆盖系统设计的改变的单元测试可以自动或手动生成；以及

- 在实现阶段（IMPL）中，基于与实现阶段相关的持久配置记录的部分，自动生成和/或监测单元测试的手动生成。

在一实施例中，第一生命周期阶段是操作阶段（OPRS），以及第二生命周期阶段是多个生命周期阶段的后续实例化的实现阶段（IMPL），并且：

- 在操作阶段（IMPL）中，使用第一自动化引擎自动检查系统日志，以检测系统元素之间的异常通信；和

- 如果检测到异常通信，则使用第一自动化引擎来更新持久配置记录的涉及多个生命周期阶段的后续实例化的实现阶段（IMPL）的部分；以及

- 在多个生命周期阶段的后续实例化的实现阶段（IMPL）中，使用第二自动化引擎自动生成模拟使用异常通信的单元测试，并测试系统对异常通信的响应。

在一实施例中，该方法包括：

- 使用被配置为实现数据分析和/或机器学习的安全性信息处理器来读取持久配置记录和/或监测第一和/或第二自动化引擎；和

- 向用户输出关于在系统的多个生命周期阶段期间观察到的事件和/或目标动作的结果。

作为示例，该方法可以包括使用机器学习算法来通过比较由不同生命周期阶段的各种微服务写入永久数据记录的记录，从而施行异常检测或异常值检测。以这种方式，机器学习算法能够将操作生命周期阶段中的事件回溯到实现、设计或规范阶段中采取的特定动作。例如，当以第一而不是第二配置配置时，使用可以在设计阶段中以第一和第二配置配置的特定软件项目的要求可能与操作阶段中的安全性漏洞利用相关联。例如，机器学习算法可以在可能涉及数百或数千名人类开发人员的长期开发过程内标识这样的微妙模式。可以使用监督学习来应用机器学习方法，其中在应用于持久数据记录之前，使用来自人类分析师的输入来训练模型。无监督学习、强化学习、贝叶斯方法、神经网络、生成对抗网络、关联规则学习和许多其它合适的技术可以应用于持久数据记录中的数据。

取决于生命周期阶段，结果可以以不同的方式输出给用户。在规范生命周期阶段中，规范中与后续生命周期阶段中不可接受的风险相关联的部分可以通过以彩色突出显示或自动生成的注释的形式突出显示规范的该部分来指示。在设计阶段中，检测到不安全的设计模式或不安全的硬件和软件规范可能触发给项目的该特定部分的设计团队成员的更新电子邮件或消息。在实现阶段中，机器学习可以生成由分析师填写的特定单元测试或单元测试存根。

根据第二方面，提供了一种包括至少一个计算装置的计算机系统，所述计算装置包括数据存储器、输入输出接口和处理器，其中所述计算机系统被配置为施行根据第一方面的方法。

根据第三方面，提供了一种包括计算机可读指令的计算机可读介质或信号，当由计算机处理器执行时，所述计算机可读指令执行根据第一方面的方法。

根据第四方面，提供了一种嵌入式软件和/或硬件系统，其根据根据第一方面的方法生成的永久配置记录来配置，其中所述嵌入式软件和/或硬件系统可选地是用于控制车辆的电子控制单元（ECU）。

附图中提供的和前述书面描述中描述的示例意图提供对本说明书原理的理解。由此不意图限制所附权利要求的范围。本说明书描述了对所图示示例的更改和修改。仅已经呈现了优选的示例，并且在说明书的范围内对这些示例的所有改变、修改和进一步应用都期望受到保护。

Claims (15)

1.一种用于在系统的多个生命周期阶段对定义可配置软件和/或硬件系统的持久配置记录（70）进行持久安全性配置监测的计算机实现的方法（10），包括：

- 在系统的第一生命周期阶段期间，根据自动化引擎的第一配置（C1）使用第一自动化引擎（EP1）自动施行第一安全性任务，其中所述第一配置定义要由第一自动化引擎（EP1）施行的目标动作（a），以及由第一自动化引擎（EP1）可检测的触发目标动作（a）的事件；

- 使用第一自动化引擎（EP1）检测事件；

- 在检测到事件时，使用第一自动化引擎（EP1）更新与第一生命周期阶段相关的持久配置记录的一部分；以及

- 响应于事件的检测，经由第一自动化引擎（EP1）触发至少一个安全性任务。

2.根据权利要求1所述的计算机实现的方法（10），

其中所述至少一个安全性任务包括：

- 用第一和第二条目更新定义系统的持久配置记录（70）的一部分，其中所述第一条目声明检测到事件，并且其中所述第二条目是记录检测到事件的生命周期阶段的生命周期阶段标识符，从而使得能够将事件的发生从第一生命周期阶段传送到第二生命周期阶段。

3.根据权利要求2所述的计算机实现的方法（10），进一步包括：

- 在系统的第二生命周期阶段期间，使用第二自动化引擎（EP2）读取持久配置记录（70）的与系统的第二生命周期阶段相关的部分中的条目；

- 将持久配置记录的读取部分中声明检测到事件的条目与由第二自动化引擎（EP2）的第二配置定义的第二目标动作进行比较；以及

- 基于比较的结果，使用第二自动化引擎（EP2）实例化要由第二自动化引擎施行的第二安全性任务和/或由第二自动化引擎（EP2）控制的进一步处理操作。

4.根据权利要求2或3之一所述的计算机实现的方法（10）,

其中所述第一生命周期阶段在第二生命周期阶段已经开始之前完成，使得持久配置记录（70）的更新部分将事件的发生传送到未来的生命周期阶段中。

5.根据权利要求2或3之一所述的计算机实现的方法（10）,

其中所述第二生命周期阶段在系统的多个生命周期阶段的后续实例化的第一生命周期阶段已经开始之前完成。

6.根据权利要求5所述的计算机实现的方法（10），

其中所述第一生命周期阶段是操作阶段（OPRS），以及第二生命周期阶段是多个生命周期阶段的后续实例化的规范阶段（SPEC），并且：

- 在操作阶段中，第一自动化引擎（EP1）被配置为针对新的安全性漏洞的发布监测威胁数据库，并且用定义新的安全性漏洞的新记录来更新与系统的规范阶段（SPEC）相关的持久配置记录的一部分；以及

- 在多个生命周期阶段的后续实例化的规范阶段（SPEC）中，检查包括在与规范阶段（SPEC）相关的持久配置记录的部分中的系统的攻击树。

7.根据权利要求5所述的计算机实现的方法（10），

其中所述第一生命周期阶段是操作阶段（OPRS），以及第二生命周期阶段是多个生命周期阶段的后续实例化的规范阶段（SPEC），并且：

- 在操作阶段中，使用第一自动化引擎观察，以获得关于与系统相关的威胁环境的定性信息；

- 在操作阶段中，使用第一自动化引擎更新与规范阶段相关联的永久配置记录的一部分；以及

- 在多个生命周期阶段的后续实例化的规范阶段（SPEC）中，使用第二自动化引擎来调整在与规范阶段相关联的持久配置记录的部分中定义的系统或系统组件的威胁评估分数。

8.根据权利要求4所述的计算机实现的方法（10），

其中所述第一生命周期阶段是设计阶段（DSGN），以及第二生命周期阶段是实现阶段（IMPL），并且所述方法进一步包括：

- 在设计阶段中，使用第一自动化引擎检测在定义系统设计的永久配置记录（70）的一部分中表达的系统设计的改变；

- 在设计阶段中，使用第一自动化引擎（EP1）更新与实现阶段相关的持久配置记录的一部分，使得覆盖系统设计的改变的单元测试可以自动或手动生成；以及

- 在实现阶段（IMPL）中，基于与实现阶段相关的持久配置记录的部分，自动生成和/或监测单元测试的手动生成。

9.根据权利要求5所述的计算机实现的方法（10），

其中所述第一生命周期阶段是操作阶段（OPRS），以及第二生命周期阶段是多个生命周期阶段的后续实例化的实现阶段（IMPL），并且：

- 在操作阶段（IMPL）中，使用第一自动化引擎自动检查系统日志，以检测系统元素之间的异常通信；和

- 如果检测到异常通信，则使用第一自动化引擎来更新持久配置记录的涉及多个生命周期阶段的后续实例化的实现阶段（IMPL）的部分；以及

- 在多个生命周期阶段的后续实例化的实现阶段（IMPL）中，使用第二自动化引擎自动生成模拟使用异常通信的单元测试，并测试系统对异常通信的响应。

10.根据权利要求8或9之一所述的计算机实现的方法（10），进一步包括：

- 将第二自动化引擎耦合到被配置为复制系统的一个或多个硬件组件的硬件在环试验台（38）；和

- 使用硬件在环试验台施行单元测试。

11.根据前述权利要求之一所述的计算机实现的方法（10），进一步包括：

- 建立托管至少一个微服务（44，45，46，48）的面向服务的架构平台，所述至少一个微服务（44，45，46，48）通信地耦合到第一和/或第二自动化引擎；

- 使用所述至少一个微服务施行第一和/或第二安全性任务。

12.根据前述权利要求之一所述的计算机实现的方法（10），进一步包括：

- 使用被配置为实现数据分析和/或机器学习的安全性信息处理器来读取持久配置记录（70）和/或监测第一和/或第二自动化引擎；和

- 向用户输出关于在系统的多个生命周期阶段期间观察到的事件和/或目标动作的结果。

13.一种计算机系统（20），包括至少一个计算装置，所述计算装置包括数据存储器（26）、输入输出接口（24）和处理器（28），其中所述计算机系统被配置为施行根据权利要求1至12之一所述的方法（10）。

14.一种计算机可读介质或信号，包括计算机可读指令，当由计算机处理器执行时，所述计算机可读指令执行根据权利要求1至11之一所述的方法。

15.一种嵌入式软件和/或硬件系统（20），根据根据方法权利要求1至11之一生成的永久配置记录来配置，其中所述嵌入式软件和/或硬件系统可选地是用于控制车辆的电子控制单元（22）。

Images