Patent Description:
Patent document <CIT>, according to its summary, states that: systems, non-transitory computer readable media, and computer-executable methods are disclosed to facilitate testing of nodes on a network that communicate according to a particular protocol. A testing system may be substituted for a particular node on a network. The testing system may include a computer system that is equipped with node instructions that are executable by the testing system to perform functions that would be performed by the particular node.

There is described herein a testing device, according to claim <NUM>, comprising: a first interface device configured to enable communication with a first component of a vehicle and a second interface device configured to enable communication with a second component of the vehicle. The testing device includes a test module storage configured to store one or more test modules. The testing device also includes a user interface and a test controller. The test controller is responsive to the user interface to select a test module from the test module storage and to cause the first interface device to communicate first test data to the first component of the vehicle and to cause the second interface device to communicate second test data to the second component of the vehicle to perform a cybersecurity vulnerability test associated with the selected test module, wherein transmission of the first test data and the second test data to the first component and the second component of the vehicle, respectively, occurs at least partially overlapping in time, and wherein an interplay between the first test data affecting operation of the first component and the second test data affecting operation of the second component indicates whether the first component and the second components are vulnerable to a multi-vector cybersecurity attack.

There is also described herein, a computer-readable storage device includes instructions, that when executed, cause one or more processors to perform operations. The operations include selecting a test module that is executable to perform, via multiple interface devices, a vulnerability test of one or more components of a vehicle. The operations also include executing the test module to perform the vulnerability test, where the vulnerability test includes communicating test data, via one or more of the multiple interface devices, to the one or more components of the vehicle.

The features, functions, and advantages described herein can be achieved independently in various examples or may be combined in yet other examples, further details of which can be found with reference to the following description and drawings.

There is also described herein, a method of vehicle testing, according to claim <NUM>, which includes selecting, at a testing device, a test module that is executable by the testing device to perform, via first and second interface devices, a cybersecurity vulnerability test of first and second components of a vehicle. The method also includes executing, at the testing device, the test module to perform the cybersecurity vulnerability test, where the cybersecurity vulnerability test includes communicating first test data, via the first interface device, to the first component of the vehicle, and communicating second test data, via the second interface device, to the second component of the vehicle. Transmission of the first test data and the second test data to the first component and the second component of the vehicle, respectively, occurs at least partially overlapping in time. An interplay between the first test data affecting operation of the first component and the second test data affecting operation of the second component indicates whether the first component and the second components are vulnerable to a multi-vector cybersecurity attack.

There is also described herein, a computer-readable storage device which includes instructions, that when executed, cause one or more processors to perform operations. The operations include the method steps of the aforementioned method according to claim <NUM>.

Aspects disclosed herein include systems and methods for testing of electronic components such as those found in vehicles. A testing device includes multiple communication interfaces configured to inject messages on various busses and media of the electronic components, such as serial busses and other wired and wireless communication channels. According to various aspects, the testing device is vehicle and platform independent (i.e., the testing device can be used or reused on different vehicles). In some examples the systems use a central repository coupled to a publication or subscription model to distribute tests of known threats and countermeasures. In some implementations, a testing system that includes the testing device provides continuously updated testing information while reducing (e.g., eliminating) the need for operator intervention in updating testing software.

In some implementations, the testing device operates as a hardware aircraft interface device that injects messages (e.g., test data) to one or more components of an aircraft via various aircraft-specific communication buses, such as an avionics bus that operates according to an Aeronautical Radio, Inc. (ARINC) <NUM>-type data transfer standard ("ARINC" is a registered trademark of ARINC Incorporated of Annapolis, Maryland), a military standard <NUM> (MIL-SPEC-<NUM>) serial data bus standard, one or more other communication standards, or any combination thereof, as illustrative, non-limiting examples. According to various implementations, the testing device is configured to perform testing on components during production of an aircraft, to perform post-production operational platform testing, to perform testing of one or more components at a testbench in a laboratory setting, or any combination thereof.

A technical effect of the disclosed testing systems and techniques is to enable uniformity of testing on various types of commercial airplanes using a testing device. In certain examples the testing systems may be used in certification, for example, for Federal Aviation Administration (FAA)-type certification and attestation and to provide a method to re-baseline (e.g., to re-perform cybersecurity or functional testing of) aircraft or aircraft components. In accordance with some aspects, the testing systems and techniques provide the ability to rollback to previous versions of testing software. In other examples, the various aspects are applicable to commercial avionics, military embedded systems, and ARINC protocols, as illustrative, non-limiting examples.

In an example, to better identify security vulnerabilities upstream in a product development lifecycle, cyber security practices are integrated into the software development phase. To facilitate automated testing, testing modules are developed and prioritized at a software repository based on cybersecurity attack events. In some implementations, an overlay threat intelligence feed is used to customize test modules for specific threat actors. In an illustrative example, the testing device is loaded with a suite of cybersecurity test modules (e.g., software, scripts, and test data) targeted at ARINC <NUM>, ARINC <NUM>, ARINC <NUM>, ARINC <NUM>, and MIL-STD-<NUM> systems. An operator of the testing device can select specific tests for an interface to one or more components under test, including cybersecurity vulnerability testing and functional testing. A technical effect of using test modules from such a software repository is uniformity of testing between different avionic system on various commercial or military aircraft or other vehicles or systems. Another technical effect is to provide remote cybersecurity vulnerability testing expertise for distributed testing as compared to performing ad-hoc, individual testing by trained cybersecurity test engineers and to provide a training mechanism for relatively unexperienced cybersecurity engineers. According to some aspects, copies or variations of the software repository and the testing device are implemented at a secure location to support customized testing for military avionics and embedded systems.

The figures and the following description illustrate specific examples. It will be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles described herein and are included within the scope of the claims that follow this description. Furthermore, any examples described herein are intended to aid in understanding the principles of the disclosure and are to be construed as being without limitation. As a result, this disclosure is not limited to the specific examples described below, but by the claims.

Particular implementations are described herein with reference to the drawings. In the description, common features are designated by common reference numbers throughout the drawings. In some drawings, multiple instances of a particular type of feature are used. Although these features are physically and/or logically distinct, the same reference number is used for each, and the different instances are distinguished by addition of a letter to the reference number. When the features as a group or a type are referred to herein (e.g., when no particular one of the features is being referenced), the reference number is used without a distinguishing letter. However, when one particular feature of multiple features of the same type is referred to herein, the reference number is used with the distinguishing letter. For example, referring to <FIG>, multiple test modules are illustrated and associated with reference numbers 142A, 142B, etc. When referring to a particular one of these test modules, such as test module 142A, the distinguishing letter "A" is used. However, when referring to any arbitrary one of these test modules or to these test modules as a group, the reference number <NUM> is used without a distinguishing letter.

As used herein, various terminology is used for the purpose of describing particular implementations only and is not intended to be limiting. For example, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. Further, some features described herein are singular in some implementations and plural in other implementations. For ease of reference herein, such features are generally introduced as "one or more" features, and are subsequently referred to in the singular unless aspects related to multiple of the features are being described.

The terms "comprise," "comprises," and "comprising" are used interchangeably with "include," "includes," or "including. " Additionally, the term "wherein" is used interchangeably with the term "where. " As used herein, "exemplary" indicates an example, an implementation, and/or an aspect, and should not be construed as limiting or as indicating a preference or a preferred implementation. As used herein, an ordinal term (e.g., "first," "second," "third," etc.) used to modify an element, such as a structure, a component, an operation, etc., does not by itself indicate any priority or order of the element with respect to another element, but rather merely distinguishes the element from another element having a same name (but for use of the ordinal term). As used herein, the term "set" refers to a grouping of one or more elements, and the term "plurality" refers to multiple elements.

As used herein, "generating," "calculating,", "using," "selecting," "accessing," and "determining" are interchangeable unless context indicates otherwise. For example, "generating," "calculating," or "determining" a parameter (or a signal) can refer to actively generating, calculating, or determining the parameter (or the signal) or can refer to using, selecting, or accessing the parameter (or signal) that is already generated, such as by another component or device. As used herein, "coupled" can include "communicatively coupled," "electrically coupled," or "physically coupled," and can also (or alternatively) include any combinations thereof. Two devices (or components) can be coupled (e.g., communicatively coupled, electrically coupled, or physically coupled) directly or indirectly via one or more other devices, components, wires, buses, networks (e.g., a wired network, a wireless network, or a combination thereof), etc. Two devices (or components) that are electrically coupled can be included in the same device or in different devices and can be connected via electronics, one or more connectors, or inductive coupling, as illustrative, non-limiting examples. In some implementations, two devices (or components) that are communicatively coupled, such as in electrical communication, can send and receive electrical signals (digital signals or analog signals) directly or indirectly, such as via one or more wires, buses, networks, etc. As used herein, "directly coupled" is used to describe two devices that are coupled (e.g., communicatively coupled, electrically coupled, or physically coupled) without intervening components.

<FIG> depicts an example of a system <NUM> that is configured to perform testing of vehicle components. While other testing schemes are contemplated, such as functional testing as described further with reference to <FIG>, the example system <NUM> is configured for cybersecurity testing. The system <NUM> includes a testing device <NUM> that is coupled to a vehicle <NUM> via one or more networks to enable data communications. For example, the testing device <NUM> is coupled to the vehicle <NUM> via one or more wireless networks or buses, one or more wireline networks or buses, or any combination thereof.

The testing device <NUM> includes a first interface device <NUM>, a second interface device <NUM>, and one or more other interface devices including an Nth interface device <NUM>. The interface devices <NUM>-<NUM> are coupled to a test controller <NUM>. The test controller <NUM> is coupled to a user interface <NUM> and to a test module storage <NUM>.

In some implementations, such as described further with reference to <FIG>, one or more of the interface devices <NUM>-<NUM> includes one or more of a radiofrequency interface, a wired ethernet-type interface, or an avionics serial bus interface. The first interface device <NUM> is configured to enable communication with a first component <NUM> of the vehicle <NUM>. In an example, the first interface device <NUM> includes a radiofrequency communication device, such as an antenna, a transponder, or a combination thereof, or a wired network interface, such as an avionics card or field-programmable gate array (FPGA) device that includes a serial bus endpoint or an ethernet-type communication interface, as described further below. Similarly, the second interface device <NUM> is configured to enable communication with a second component <NUM> of the vehicle <NUM>. In some implementations, one or more of the interface devices <NUM>-<NUM> are configured to communicate with components of the vehicle <NUM> via one or more breakout cables that are incorporated in the vehicle <NUM> for testing purposes during manufacture of the vehicle <NUM> and that are later removed from the vehicle <NUM> upon completion of manufacture.

In some implementations, one or more of the interface devices <NUM>-<NUM> are configured to enable communication with one or more additional components of the vehicle <NUM>, such as the Nth interface device <NUM> configured to enable communication with an Mth component <NUM>. As used herein, N and M are integers greater than two. In some implementations N equals M, while in other implementations N is greater than M or is less than M. Although examples are provided herein that describe testing using the first interface device <NUM> and the second interface device <NUM> to communicate data to the first component <NUM> and the second component <NUM>, respectively, such examples are provided for clarity of explanation and should not be considered limiting.

The test module storage <NUM> is configured to store one or more test modules <NUM> that include data <NUM> to perform vulnerability tests, such as cybersecurity vulnerability tests <NUM> via the first interface device <NUM> and the second interface device <NUM>. For example, a first test module 142A in the test module storage <NUM> includes first data 144A. The first data 144A includes first test data <NUM> configured to be communicated to the first component <NUM> of the vehicle <NUM>, second test data <NUM> configured to be communicated to the second component <NUM> of the vehicle <NUM>, and in various implementations includes additional test data configured to be communicated to one or more of the components <NUM>-<NUM> of the vehicle <NUM> to perform a first cybersecurity vulnerability test 146A. A second test module 142B includes second data 144B configured to be communicated to one or more of the components <NUM>-<NUM> of the vehicle <NUM> to perform a second cybersecurity vulnerability test 146B that is different from the first cybersecurity vulnerability test 146A.

The user interface <NUM> includes one or more devices, such as one or more buttons, keyboards, pointing devices, displays, speakers, microphones, touch screens, or other devices, or any combination thereof, to enables an operator of the testing device <NUM> to select and initiate performance of cybersecurity vulnerability testing. The user interface <NUM> provides a mechanism of simplifying cybersecurity-style attack testing that enables relatively unskilled technicians to run cybersecurity vulnerability testing via the user interface <NUM> without necessarily having an underlying understanding of the details and procedures involved with each of the test modules <NUM>.

In an example, the test module storage <NUM> stores a suite of cybersecurity vulnerability tests <NUM> that are executable via the test controller <NUM> and the interface devices <NUM>-<NUM> to perform sequenced cybersecurity-style attacks using the interface devices <NUM>-<NUM>. In some implementations, the test modules <NUM> are loaded to the test module storage <NUM> from an external cybersecurity software repository (e.g., remote from the testing device <NUM>), such as described further with reference to <FIG>. In an example, the test modules <NUM> are selected to be loaded from the external software repository based on a testing priority associated with a threat intelligence feed.

As used herein, a cybersecurity-style attack is an attack in which maliciously crafted software payloads are communicated (e.g. as a computer-implemented method), such as messages that have specific statements that cause remote code execution or that cause unavailability of one or more portions of one or more of the components <NUM>-<NUM>. In an illustrative example, a cybersecurity-style attack includes malware exploits that target vehicle specific components, such airplane-specific line-replaceable units (LRUs) in implementations in which the vehicle <NUM> is an aircraft. Examples of LRUs include, but are not limited to, radios, transponders, sensors, aircraft condition monitoring systems, flight data acquisition units, flight maintenance computers, and aircraft communications and reporting systems. As used herein, a cybersecurity vulnerability test is a test that performs a cybersecurity-style attack, emulates a cybersecurity-style attack, or probes for vulnerabilities that may be exploitable by a cybersecurity-style attack (e.g. as a computer-implemented method). One example of a cybersecurity vulnerability test includes duplicating a buffer overflow attack by attempting to write data beyond a designated memory region for storage of the data. Another example of a cybersecurity vulnerability attack includes duplicating or emulating a ransomware attack that is based on exploiting one or more potential hardware or software vulnerabilities.

In some implementations, an operator of the testing device <NUM> selects a suite of test modules to perform cybersecurity vulnerability testing of the vehicle <NUM>, and the test controller <NUM> is configured to translate user commands received via the user interface <NUM>, such as high-level commands, to select one or more test module <NUM>, such as the test module 142A, to perform an associated cybersecurity vulnerability test <NUM>, e.g., the first cybersecurity vulnerability test 146A, via the interface devices <NUM>-<NUM>. Additional details and examples of various implementations of cybersecurity-style attacks are described further with reference to <FIG>.

As presently claimed, the test controller <NUM> is responsive to the user interface <NUM> to select the test module 142A from the test module storage <NUM> and is responsive to the user interface <NUM> to cause the first interface device <NUM> to communicate the first test data <NUM> to the first component <NUM> of the vehicle <NUM>. In addition, the test controller <NUM> causes the second interface device <NUM> to communicate the second test data <NUM> to the second component <NUM> of the vehicle <NUM> to perform the first cybersecurity vulnerability test 146A associated with the selected test module 142A.

During operation, an operator of the testing device <NUM> selects, via the user interface <NUM>, one or more test modules <NUM> to be executed as part of a cybersecurity vulnerability testing of the vehicle <NUM> (e.g. as a computer-implemented method). In an example, the operator selects the first cybersecurity vulnerability test 146A associated with the test module 142A to be performed.

In response to selection of the test module 142A via the user interface <NUM>, the test controller <NUM> accesses the selected test module 142A and retrieves the first data 144A, including the first test data <NUM> and the second test data <NUM>. The test controller <NUM> controls communication of the first test data <NUM> to the first interface device <NUM> to be communicated to the first component <NUM> and also controls communication of the second test data <NUM> to the second interface device <NUM> to be communicated to the second component <NUM>. As presently claimed, transmission of the first test data <NUM> and the second test data <NUM> to the first and second components <NUM> and <NUM>, respectively, of the vehicle <NUM>, respectively, occurs simultaneously (e.g., at least partially overlapping in time). In some implementations, operation of the components under test of the vehicle <NUM> is monitored to determine an effect of the data communication from the testing device <NUM>. In an illustrative example, the first test data <NUM> communicated to the first component <NUM> includes data emulating a stack overflow or other memory overflow attack in which an amount of data transmitted via the first interface device <NUM> exceeds an allowed amount of data according a communication protocol that is supported by the first component <NUM>. The second test data <NUM> communicated to the second component <NUM> is configured to cause the second component <NUM> to perform one or more functions that contribute to an exploit of the stack overflow or memory attack at the first component <NUM>. As presently claimed, an interplay between the first test data <NUM> affecting the operation of the first component <NUM> and the second test data <NUM> the affecting the operation of the second component <NUM> indicates whether the first and second components <NUM>, <NUM> are vulnerable to a multi-vector cybersecurity attack.

In some implementations, results of the cybersecurity vulnerability testing are fed back to the testing device <NUM> and stored and presented to an operator via the user interface <NUM>, are observed by watching operation of one or more systems of the vehicle <NUM>, or a combination thereof. In an example, results are observed as indications appearing at one or more instrumentation light displays or other user interface components of the vehicle <NUM> that indicate, directly or indirectly, one or more fault conditions arising from a successful cybersecurity vulnerability attack.

Although <FIG> depicts the testing device <NUM> including more than two interface devices <NUM>-<NUM> that provide the technical effect of enabling multiple-vector cybersecurity vulnerability testing that involves multiple components <NUM>-<NUM> of the vehicle <NUM>, in other implementations the testing device <NUM> includes the first interface device <NUM> and the second interface device <NUM> and omits additional interface devices (e.g., omits the Nth interface device <NUM>). Although the test module storage <NUM> is depicted in the testing device <NUM>, in other implementations part or all of the test module storage <NUM> is external to the testing device <NUM>.

Although each of the interface devices <NUM>-<NUM>, the test controller <NUM>, the user interface <NUM>, and the test module storage <NUM> are depicted as separate components, in other implementations the described functionality of two or more of the interface devices <NUM>-<NUM>, the test controller <NUM>, the user interface <NUM>, and the test module storage <NUM> is performed by a single component. In some implementations, the interface devices <NUM>-<NUM>, the test controller <NUM>, the user interface <NUM>, and the test module storage <NUM> are each represented in hardware, such as via an application-specific integrated circuit (ASIC) or a field-programmable gate array (FPGA), or the operations described with reference to the elements may be performed by a processor executing computer-readable instructions (e.g. as a computer-implemented method).

<FIG> depicts an illustrative example <NUM> of the testing device <NUM>. As illustrated, each of the interface devices <NUM>-<NUM> includes one or more of a wireless interface (e.g., radiofrequency interface), a wired interface (e. g, Ethernet, serial, and the like), or an avionics bus interface (e.g., <NUM>, ARINC, and the like). For example, the first interface device <NUM> includes a serial bus interface (I/F) <NUM>, illustrated as an avionics serial bus interface <NUM> for use during testing of an aircraft or one or more LRUs of an aircraft. The second interface device <NUM> includes a wired ethernet-type interface <NUM>. The Nth interface device <NUM> includes a radiofrequency (RF) interface <NUM>. Each of the interface devices <NUM>-<NUM> is associated with a corresponding protocol, such as a first protocol <NUM> associated with the serial bus interface <NUM>, a second protocol <NUM> associated with the wired ethernet-type interface <NUM>, and a third protocol <NUM> associated with the radiofrequency interface <NUM>. In an illustrative, non-limiting example, the interface devices <NUM>-<NUM> include communication hardware and protocol stacks corresponding to one or more of: ARINC <NUM>, ARINC <NUM>, ARINC <NUM>, ARINC <NUM> (e.g., ARINC <NUM> part <NUM>), ARINC <NUM>, ARINC <NUM>, MIL-STD-<NUM>, IEEE <NUM>, one or more location protocols such as GPS or global navigation satellite system (GNSS), one or more other protocols or interfaces, or any combination thereof.

The testing device <NUM> includes a testing partition <NUM> and an update partition <NUM>. As used herein, a "partition" corresponds to a designated region of memory that is logically or physically distinct from other regions of memory, such as one or more designated memory regions of a memory device or one or more designated physical memory devices. In some implementations, a partition differs from other memory regions of a memory system by having a different file system format, different access permissions, different encryption settings, or any combination thereof, as illustrative, non-limiting examples. The testing partition <NUM> includes the first interface device <NUM>, the second interface device <NUM>, the Nth interface device <NUM>, the user interface <NUM>, and the test controller <NUM>. The update partition <NUM> includes the test module storage <NUM>, a hardware lock <NUM>, and a communication interface <NUM>. The hardware lock <NUM> is configurable to selectively enable or prevent an update of the one or more test modules <NUM> that have been loaded to the testing partition <NUM>. In an example, the hardware lock <NUM> includes a switch that couples communication lines to enable data transfer when the switch is engaged and that decouples the communication lines to disable data transfer when the switch is disengaged. Engaging (or "locking") the hardware lock <NUM> includes disengaging the switch, and disengaging (or "unlocking") the hardware lock <NUM> includes engaging the switch. After one or more test modules have been loaded from the test module storage <NUM> to the testing partition <NUM>, the hardware lock <NUM> is manually or electronically set (e.g., engaged) to prevent updates of the test module(s) at the testing partition <NUM> until after completion of testing that uses the test module. Engaging the hardware lock <NUM> prevents on-the-fly changes to one or more of the test modules <NUM> from occurring due to receiving update data from the test module storage <NUM> during testing, such as in compliance with FAA testing criteria.

In addition to the test modules <NUM>, the test module storage <NUM> is configured to store one or more additional test modules <NUM> to enable functional testing of components of the vehicle <NUM>, such as functional testing of the first component <NUM> and the second component <NUM> of <FIG>. To illustrate, the test module storage <NUM> includes a first functional test module 242A that includes first functional test data 244A executable by the test controller <NUM> to perform a first functional test 246A. The test module storage <NUM> also includes a second functional test module 242B that includes second functional test data 244B executable by the test controller <NUM> to perform a second functional test 246B. In contrast to the "negative" testing corresponding to the cybersecurity vulnerability tests <NUM> to test for failures or vulnerabilities associated with cyber-attacks, as described with reference to the test modules <NUM>, the functional tests <NUM> are configured for performance of "positive" testing that tests an operational capability of the vehicle components <NUM>-<NUM> in accordance with normal (e.g., non-cyber attack) operation of the vehicle components <NUM>-<NUM>.

The communication interface <NUM> is coupled to the test module storage <NUM> and is configured to enable loading of the one or more test modules <NUM> from an external cybersecurity repository, such as described further with reference to <FIG>. In addition, the communication interface <NUM> is configured to enable loading of the one or more functional test modules <NUM>, such as from a functional testing software repository.

During operation, the test modules <NUM> and the functional test modules <NUM> are loaded to the update partition <NUM> via the communication interface <NUM>. The test modules <NUM> and the functional test modules <NUM> are stored in the test module storage <NUM>.

In some implementations, the test controller <NUM> receives, from the user interface <NUM>, a selection of one or more test modules from an operator of the testing device <NUM>. In response, the test controller <NUM> is configured to retrieve one or more of the selected test modules from the test module storage <NUM> and to provide associated data to be communicated via the interface devices <NUM>-<NUM> to execute the associated test(s). In an illustrative example, in response to selection, at the user interface <NUM>, of the first test module 142A, the test controller <NUM> retrieves the first test data <NUM> and the second test data <NUM> from the test module storage <NUM>. After retrieving the first test data <NUM> and the second test data <NUM>, the hardware lock <NUM> is engaged (e.g., set to a locked position that physically interrupts data communication between the testing partition <NUM> and the update partition <NUM>) to prevent changes to the first test data <NUM> and the second test data <NUM> at the testing partition <NUM>. In an illustrative, non-limiting example, the operator of the testing device <NUM> manually actuates a switch that decouples data bus lines at the testing partition <NUM> from corresponding data bus lines at the update partition <NUM>.

In some implementations, the first interface device <NUM> is configured to communicate the first test data <NUM> to the first component <NUM> of the vehicle <NUM> in violation of the first protocol <NUM> associated with the first interface device <NUM>, and the second interface device <NUM> is configured to communicate the second test data <NUM> to the second component <NUM> in violation of the second protocol <NUM> associated with the second interface device <NUM>. For example, in an implementation in which the first protocol <NUM> specifies a payload size (e.g., a largest amount of data that is permitted to be transferred in a data packet) for the avionics serial bus interface <NUM>, communicating the first test data <NUM> in violation of the first protocol <NUM> includes transmitting the first test data <NUM> using a payload size that exceeds the payload size specified by the first protocol <NUM>. In this manner, a cybersecurity-style attack can be emulated that exploits a stack overflow or memory overflow condition of the first component <NUM>. In an implementation in which the second protocol <NUM> defines an acceptable range of clock frequencies or an allowed packet payload size, transmitting the second test data <NUM> in violation of the second protocol <NUM> includes transmission of at least a portion of the second test data <NUM>, using a clock frequency outside of the acceptable range of clock frequencies, using a packet payload size in excess of the allowed payload size, using one or more other violations of the second protocol <NUM>, or combination thereof. In an implementation in which the third protocol <NUM> defines a range of frequencies or channels permissible for use with the radiofrequency interface <NUM>, transmitting test data in violation of the third protocol <NUM> includes transmission of cybersecurity test data via one or more frequencies or channels not specified by the third protocol <NUM>, using a packet payload size in excess of an allowed payload size indicated by the third protocol <NUM>, sending wireless signaling traffic that emulates a denial of service (DOS) attack or a global positioning service (GPS) attack, one or more other violations of the third protocol <NUM>, or combination thereof. In this manner, the testing device <NUM> is configured to perform a cybersecurity-style vulnerability test that emulates exploitation of one or more potential vulnerabilities of one or more components <NUM>-<NUM> of the vehicle <NUM> arising from violations of the associated protocols <NUM>-<NUM>.

In a particular implementation, the test controller <NUM> receives, from the user interface <NUM>, selection of one or more of the functional tests <NUM> for performance of functional testing of one or more of the components <NUM>-<NUM>. In response, the test controller <NUM> retrieves the associated data (e.g., the first functional test data 244A associated with the first functional test module 242A) to perform the selected functional test (e.g., the first functional test 246A). The test controller <NUM> initiates the selected functional test by providing the retrieved functional test data <NUM> to one or more of the interface devices <NUM>-<NUM> for communication of the functional test data <NUM> in accordance with the associated protocol <NUM>-<NUM> to perform functional (i.e., non-cybersecurity vulnerability) testing of one or more of the components <NUM>-<NUM>.

In some implementations, after completion of one or more of the selected tests, an operator of the testing device <NUM> manually adjusts a setting of the hardware lock <NUM> to allow modification of data at the testing partition <NUM>, such as to load a next test module <NUM> or <NUM> from the update partition <NUM> to the testing partition <NUM> to perform a next test. In other implementations, the hardware lock <NUM> is adjusted based on control signals from the test controller <NUM> (instead of being manually set by an operator or the testing device), such as in response to a user input at the user interface <NUM>.

By performing cybersecurity vulnerability tests selected from the test module storage <NUM>, the test controller <NUM> provides the technical effect of enabling cybersecurity testing at the testing device <NUM> to determine vulnerability to one or more exploits associated with communications in violation of the associated protocols <NUM>-<NUM>. In addition, in the example <NUM> of <FIG>, the testing device <NUM> is configurable to perform non-cybersecurity functional testing via the same interface devices <NUM>-<NUM> functioning in accordance with the associated protocols <NUM>-<NUM>. A technical effect is that a variety of testing types (e.g., cybersecurity vulnerability testing and function testing) can be performed using a single testing device <NUM> rather than requiring multiple testing devices to perform the different testing types. A technical effect of the hardware lock <NUM> is to enable isolation of the testing partition <NUM> during testing, preventing modification of testing data at the testing partition <NUM> while the test is ongoing. Additionally, the communication interface <NUM> provides a mechanism by which one or more test modules can be loaded to the test module storage <NUM> from external repositories, such as the cybersecurity software repository as described with reference to <FIG>, and provides the technical effect of enabling loading standardized test modules from a remote or centralized repository, reducing cost and complexity associated with ad-hoc, individualized testing of components or systems.

Referring to <FIG>, a particular implementation of a system <NUM> is depicted that includes the testing device <NUM>, a cybersecurity software repository <NUM> that includes a cybersecurity test suite module <NUM>, and a threat intelligence feed <NUM>. The cybersecurity test suite module <NUM> includes one or more test modules, such as the first test module 142A and the second test module 142B. Although a single cybersecurity test suite module <NUM> is illustrated in the cybersecurity software repository <NUM>, in other implementations the cybersecurity software repository <NUM> includes multiple cybersecurity test suite modules, each of which includes one or more test modules associated with a corresponding set of cybersecurity attacks (e.g. as computer-implemented methods), one or more test modules from a test module supplier, such as according to a subscription service, or another logical grouping of test modules.

A testing priority <NUM> is determined based on the threat intelligence feed <NUM>. For example, the threat intelligence feed <NUM> includes information associated with known cyber-attacks, such as cyber-attacks detected as being performed by a state-sponsored actor. As an illustration, when a particular state or other actor or organization is known to be performing buffer overflow attacks and is considered to be a relatively high-priority threat, test modules associated with buffer overflow attacks are determined to have a relatively high testing priority as compared to other cybersecurity attacks. In another example, the threat intelligence feed <NUM> includes information regarding other cybersecurity-style attacks, such as ransomware or other attacks determined to be relevant and occurring at a higher likelihood as compared other cybersecurity attacks. The testing priority <NUM> indicates, based on the information regarding potential cyber-attacks indicated in the threat intelligence feed <NUM>, a prioritization of cybersecurity test modules that are associated with the potential cyber-attacks and that are to be used for vulnerability testing. The testing priority <NUM> is used to determine one or more cybersecurity test suite module to be loaded to the testing device <NUM>, such as to select the cybersecurity test suite module <NUM> to perform cybersecurity vulnerability testing in accordance with the first test module 142A and the second test module 142B. The test modules <NUM> are selected to be loaded from the external cybersecurity software repository <NUM> to the testing device <NUM> based on the testing priority <NUM>, which in turn is based on the threat intelligence feed <NUM>.

In some implementations, the testing priority <NUM> is a data structure that includes an ordered list of cybersecurity vulnerability tests or test modules that indicates a relative priority of each of the items in the list. In other implementations, the testing priority <NUM> includes multiple priorities <NUM> of test cases, such as a priority 330A (e.g., a numerical value) indicating a relative or absolute priority value for the first test module 142A and a priority 330B indicating a relative or absolute priority value for the second test module 142B.

In a particular implementation of operation of the system <NUM>, the testing device <NUM> receives an application programming interface (API) key <NUM>. The API key <NUM> is associated with a subscription to a cybersecurity test module from a test provider, such as the cybersecurity test module <NUM> that includes the first test module 142A. The testing device <NUM> accesses the cybersecurity test module <NUM> via the API key <NUM> to load the cybersecurity test suite module <NUM> to the testing device <NUM>. The testing device <NUM> executes testing associated with each of the test modules <NUM> of cybersecurity test suite module <NUM>, including executing the first test module 142A and executing the second test module 142B. The testing device <NUM> compares a result of each cybersecurity vulnerability to a pass-fail condition <NUM>. After determining a passing result or a failing result for each of the performed cybersecurity vulnerability tests, the testing device <NUM> generates an output report, such as via the user interface <NUM>.

In an illustrative example, operation of the system <NUM> includes creation of multiple cybersecurity avionics test modules <NUM> (e.g., including the first test module 142A). The testing priority <NUM> of test cases of the multiple cybersecurity avionics test modules <NUM> are set based on one or more threat intelligence feeds, such as the threat intelligence feed <NUM>. A list of test cases <NUM> is generated based on the testing priority <NUM>. One or more of the test modules <NUM> (e.g., a cybersecurity avionics test module) corresponding to the list of test cases <NUM>, including the first test module 142A, are loaded to the testing device <NUM>. Prior to executing test cases of the one or more avionics test modules <NUM>, the hardware lock <NUM> is disengaged to enable copying of the test data of the selected test module(s) from the update partition <NUM> to the testing partition <NUM> of the testing device <NUM>. After copying the test data to the testing partition <NUM>, the hardware lock <NUM> is engaged to prevent modification of the test data in the testing partition <NUM> until after performance of the tests has completed.

In some aspects, the testing device <NUM> is used in conjunction with a subscription-based model in which one or more API keys, such as the API key <NUM>, can be provided to subscribers of one or more cybersecurity test suite modules that are available at the cybersecurity software repository <NUM>. The testing priority <NUM> is determined based upon one or more threat intelligence feeds, such as the threat intelligence feed <NUM>, to provide testing priority to known vulnerability attacks that are considered to have a relatively high probability of occurrence or relatively high damage potential in the event of a successful attack. The testing priority <NUM> enables the testing device <NUM>, or an operator of the testing device <NUM>, to determine the list of test cases <NUM> to structure a sequence of cybersecurity vulnerability testing associated with the threat intelligence feed <NUM> and accessible via the subscription to the subscribed cybersecurity test suite associated with the API key <NUM>. In some implementations, additional API keys associated with other cybersecurity test modules are selectable, such as API keys that are provided with additional subscriptions, enabling an operator of the testing device <NUM> to select from among multiple providers of cybersecurity test modules, multiple types of cybersecurity testing, or a combination thereof.

<FIG> depicts an example of a method <NUM> that is performed in association with the testing device <NUM> in some implementations (e.g. as a computer-implemented method). The method <NUM> includes, at <NUM>, creating one or more cybersecurity avionics test modules, such as the first test module 142A or the second test module 142B. The method <NUM> includes, at <NUM>, setting a priority of test cases based on one or more threat intelligence feeds, such as the testing priority <NUM> that is set based on the threat intelligence feed <NUM>. The method <NUM> includes, at <NUM>, generating a recommended test case list based on threat intelligence. In an example, the list of test cases <NUM> is generated based on the testing priority <NUM>, which is based on the threat intelligence feed <NUM>.

The method <NUM> includes, at <NUM>, loading the test modules to a staging environment. In an example, the staging environment corresponds to the update partition <NUM> illustrated in <FIG>, loaded from the cybersecurity software repository <NUM> via the communication interface <NUM>.

The method <NUM> includes, at <NUM>, engaging a hardware switch to pull data onto an avionics partition, at <NUM>. In in example, engaging the hardware switch is performed by manually configuring the hardware lock <NUM> to enable to the test controller <NUM> to retrieve the first data 144A of the first test module 142A from the update partition <NUM> to the testing partition <NUM> in response to a determination to load the first test module 142A.

The method <NUM> includes, at <NUM>, executing test cases against one or more targets. To illustrate, the test controller <NUM> executes one or more of the retrieved test modules to perform cybersecurity vulnerability testing of one or more of the components <NUM>-<NUM> of the vehicle <NUM> via communication of test data using one or more of the interface devices <NUM>-<NUM>.

<FIG> depicts multiple examples of systems that include the testing device <NUM> in communication with the first component <NUM> and the second component <NUM> in various implementations. <FIG> depicts the testing device <NUM> performing cybersecurity vulnerability testing of the components <NUM>, <NUM> in a spacecraft, such as a satellite <NUM> (e.g. as a computer-implemented method). <FIG> depicts the testing device <NUM> performing cybersecurity vulnerability testing of the components <NUM>, <NUM> in an aircraft <NUM> (e.g. as a computer-implemented method). <FIG> depicts the testing device <NUM> performing cybersecurity vulnerability testing of the components <NUM>, <NUM> in a watercraft <NUM> (e.g. as a computer-implemented method). <FIG> depicts an implementation in which the testing device <NUM> performs cybersecurity vulnerability testing of the components <NUM>, <NUM> at a testbench <NUM> instead of in a vehicle (e.g. as a computer-implemented method). As illustrated, the first component <NUM> includes a first LRU <NUM> and the second component <NUM> includes a second LRU <NUM>. As used herein, a "testbench" includes one or more hardware devices, field programmable gate arrays, processors, servers, or any combination thereof, that enable testing of one or more of the components <NUM>, <NUM> or testing of software of one or more of the components <NUM>, <NUM> prior to integration of the components <NUM>, <NUM> into the vehicle <NUM>. In an illustrative, non-limiting example, a testbench includes an emulator configured to emulate an operating environment of one or more of the components <NUM>, <NUM> for testing purposes.

Although <FIG> depict testing of vehicle components at the respective vehicles <NUM>-<NUM> and at the testbench <NUM>, in other implementations the testing device <NUM> tests electronic components other than in vehicles or at a testbench. For example, in some implementations the testing device <NUM> is used to test the components <NUM>, <NUM> that are implemented at a stationary structure (e.g., an air traffic control tower).

<FIG> depicts an illustrative implementation of a method <NUM> of vehicle testing (e.g. as a computer-implemented method). In an example, one or more elements of the method <NUM> is performed by the testing device <NUM> in isolation or as part of the system <NUM> of <FIG>. Although the method <NUM> is described in conjunction with avionics testing, in other implementations the method <NUM> is instead performed in conjunction with other vehicle or non-vehicle testing, such as described with reference to <FIG>.

The method <NUM> includes, at <NUM>, obtaining multiple avionics test modules that include a test module, such as the first test module 142A. The method <NUM> includes, at <NUM>, setting priorities of test cases of the multiple avionics test modules based on one or more threat intelligence feeds, such as the testing priority <NUM> of test cases of the cybersecurity avionics test modules <NUM> based on the threat intelligence feed <NUM>. The method <NUM> includes, at <NUM>, generating a list of test cases <NUM> based on the priorities. For example, the list of test cases <NUM> is generated based on the testing priority <NUM>.

The method <NUM> includes, at <NUM>, loading one or more of the multiple avionics test modules corresponding to the list of test cases (e.g., including the test module 142A) to a testing device, such as the testing device <NUM>. In an illustrative example, the one or more test modules <NUM> are loaded from the external cybersecurity software repository <NUM> to the testing device <NUM>, where the one or more test modules <NUM> are selected to be loaded based on the testing priority <NUM>, and the testing priority <NUM> is based on the threat intelligence feed <NUM>.

In a particular implementation, loading the test modules to the testing device includes, at <NUM>, receiving an application programming interface key (e.g., the API key <NUM>) associated with a subscription to a cybersecurity test suite module, such as the cybersecurity test module <NUM> that includes the test module 142A. In the particular implementation, loading the test modules to the testing device also includes, at <NUM>, accessing the cybersecurity test suite module via the API key to load the cybersecurity test suite module to the testing device.

The method <NUM> includes, at <NUM>, prior to executing test cases of the one or more avionics test modules, disengaging a hardware lock (e.g., disengaging the hardware lock <NUM>) to enable copying of the test data from an update partition (e.g., the update partition <NUM>) to a testing partition (e.g., the testing partition <NUM>) of the testing device. After copying the test data from the update partition to the testing partition, the hardware lock is engaged to prevent data transfer from the update partition to the testing partition.

The method <NUM> includes, at <NUM>, selecting, at the testing device, a test module that is executable by the testing device to perform, via multiple interface devices, a vulnerability test of one or more components of a vehicle. In an illustrative example, the testing device <NUM> selects the test module 142A that is executable by the testing device <NUM> to perform, via the interface devices <NUM>-<NUM>, the first cybersecurity vulnerability test 146A of one or more components <NUM>-<NUM> of the vehicle <NUM>.

The method <NUM> includes, at <NUM>, executing, at the testing device, the test module to perform the vulnerability test, where the vulnerability test includes communicating test data, via one or more of the multiple interface devices, to the one or more components of the vehicle. In some implementations, communicating the test data includes initiating transmission via at least two of: a radiofrequency interface (e.g., the radiofrequency interface <NUM>); a wired ethernet-type interface (e.g., the wired ethernet-type interface <NUM>); or a serial bus interface (e.g., the serial bus interface <NUM>). In some implementations, communicating the test data to the one or more components of the vehicle violates one or more associated protocols (e.g., one or more of the protocols <NUM>-<NUM>) of the one or more of the multiple interface devices. In an illustrative example, the vulnerability test is performed during product development of the one or more components, during certification testing of the one or more components, or both.

The method <NUM> includes, at <NUM>, comparing a result of the vulnerability test to a pass-fail condition. In a non-limiting example, the testing device <NUM> compares test results to the pass-fail condition <NUM> and generates a report indicative of success or failure of the vulnerability test.

The method <NUM> includes, at <NUM>, selecting, at the testing device, one or more additional test modules that are executable by the testing device to perform functional testing of the one or more components of the vehicle, such as the additional test modules <NUM> selected responsive to operator input received via the user interface <NUM>.

The method <NUM> includes, at <NUM>, executing, at the testing device, the one or more additional test modules to perform the functional testing, where the functional testing includes communicating functional test data (e.g., functional test data <NUM>), via one or more of the multiple interface devices, to the one or more components of the vehicle.

In some implementations, the method <NUM> is performed by multiple interoperating devices or systems. In some examples, the multiple cybersecurity test modules and the multiple functional test modules are created by one or more cybersecurity testing vendors, component manufactures, governmental or regulatory agencies, other testing providers, or any combination thereof. In some examples, generating the list of test cases based on the priorities, maintaining one or more software repositories, and providing the API key to subscribers to access test modules in the software repositories is performed by one or more cybersecurity testing vendors, governmental or regulatory agencies, other testing providers, or any combination thereof. However, in other implementations, every element of the method <NUM> is performed by a single entity, such as a vehicle manufacturer.

In some implementations, one or more elements of the method <NUM> are omitted. As an illustrative, non-limiting example, in an implementation in which the test modules are generated and prioritized by one or more external vendors or suppliers, operations associated with blocks <NUM>-<NUM> are performed by the external vendors or suppliers and are omitted from the method <NUM>. In another illustrative, non-limiting example, in an implementation in which the testing device omits the hardware lock <NUM>, operations associated with block <NUM> of the method <NUM> are omitted. In another illustrative, non-limiting example, in an implementation in which functional testing is not performed, operations associated with blocks <NUM> and <NUM> are omitted from the method <NUM>.

Aspects of the disclosure can be described in the context of an example of a vehicle. A particular example of the vehicle <NUM> is an aircraft <NUM> as shown in <FIG>.

In the example of <FIG>, the aircraft <NUM> includes an airframe <NUM> with a plurality of systems <NUM> and an interior <NUM>. Examples of the plurality of systems <NUM> include one or more of a propulsion system <NUM>, an electrical system <NUM>, an environmental system <NUM>, and a hydraulic system <NUM>. Any number of other systems may be included. One or more of the systems <NUM> includes one or more of the components <NUM>-<NUM> described in <FIG> and is accessible for cybersecurity vulnerability testing by the testing device <NUM>.

<FIG> is a block diagram of a computing environment <NUM> including a computing device <NUM> configured to support aspects of computer-implemented methods and computer-executable program instructions (or code) according to the present disclosure. For example, the computing device <NUM>, or portions thereof, is configured to execute instructions to initiate, perform, or control one or more operations described with reference to <FIG> (e.g. as a computer-implemented method). In a particular implementation, the computing device <NUM> corresponds to the testing device <NUM> of <FIG>.

The computing device <NUM> includes one or more processors <NUM>. The processor(s) <NUM> are configured to communicate with system memory <NUM>, one or more storage devices <NUM>, one or more input/output interfaces <NUM>, one or more communications interfaces <NUM>, or any combination thereof. The system memory <NUM> includes volatile memory devices (e.g., random access memory (RAM) devices), nonvolatile memory devices (e.g., read-only memory (ROM) devices, programmable read-only memory, and flash memory), or both. The system memory <NUM> stores an operating system <NUM>, which may include a basic input/output system for booting the computing device <NUM> as well as a full operating system to enable the computing device <NUM> to interact with users, other programs, and other devices. The system memory <NUM> stores system (program) data <NUM>, such as the first data 144A and the second data 144B of <FIG>.

The system memory <NUM> includes one or more applications <NUM> (e.g., sets of instructions) executable by the processor(s) <NUM>. As an example, the one or more applications <NUM> include instructions executable by the processor(s) <NUM> to initiate, control, or perform one or more operations described with reference to <FIG>. To illustrate, the one or more applications <NUM> include an abstraction layer <NUM> having instructions executable by the processor(s) <NUM> to initiate, control, or perform one or more operations described with reference to the test controller <NUM>, such as receiving user input from a user interface, selecting and loading test modules based on the user input, and configuring, scheduling, and sending test data to the interface devices <NUM>, <NUM> to perform testing.

In a particular implementation, the system memory <NUM> includes a non-transitory, computer readable medium storing the instructions that, when executed by the processor(s) <NUM>, cause the processor(s) <NUM> to initiate, perform, or control operations to perform cybersecurity vulnerability testing, such as via execution of the abstraction layer <NUM> (e.g. as a computer-implemented method). The operations include selecting a test module (e.g., the test module 142A) that is executable to perform, via multiple interface devices (e.g., the interface devices <NUM>, <NUM>), a cybersecurity vulnerability test (e.g., the first cybersecurity vulnerability test 146A) of one or more components of a vehicle (e.g., the components <NUM>, <NUM> of the vehicle <NUM>). The operations also include executing the test module to perform the cybersecurity vulnerability test, where the cybersecurity vulnerability test includes communicating test data (e.g., the first test data <NUM> and the second test data <NUM>), via one or more of the multiple interface devices, to the one or more components of the vehicle. In some implementations, the operations further include selecting one or more additional test modules (e.g., test modules <NUM>) that are executable to perform functional testing of the one or more components of the vehicle, and executing the one or more additional test modules to perform the functional testing, where the functional testing includes communicating functional test data (e.g., functional test data <NUM>), via one or more of the multiple interface devices, to the one or more components of the vehicle.

In some implementations, the one or more storage devices <NUM> correspond to the test module storage <NUM> and include nonvolatile storage devices, such as magnetic disks, optical disks, or flash memory devices. In a particular example, the storage devices <NUM> include both removable and non-removable memory devices. The storage devices <NUM> are configured to store an operating system, images of operating systems, applications (e.g., one or more of the applications <NUM>), and program data (e.g., the program data <NUM>), including the first test module 142A and the second test module 142B. In a particular aspect, the system memory <NUM>, the storage devices <NUM>, or both, include tangible computer-readable media. In a particular aspect, one or more of the storage devices <NUM> are external to the computing device <NUM>.

The one or more input/output interfaces <NUM> that enable the computing device <NUM> to communicate with one or more input/output devices <NUM> to facilitate user interaction. For example, in some implementations the one or more input/output interfaces <NUM> include a display interface, an input interface, or both. For example, the input/output interface <NUM> is adapted to receive input from a user, to receive input from another computing device, or a combination thereof. In some implementations, the input/output interface <NUM> conforms to one or more standard interface protocols, including serial interfaces (e.g., universal serial bus (USB) interfaces or Institute of Electrical and Electronics Engineers (IEEE) interface standards), parallel interfaces, display adapters, audio adapters, or custom interfaces ("IEEE" is a registered trademark of The Institute of Electrical and Electronics Engineers, Inc. of Piscataway, New Jersey). In some implementations, the input/output device <NUM> includes one or more user interface devices and displays, such as the user interface <NUM>, including some combination of buttons, keyboards, pointing devices, displays, speakers, microphones, touch screens, and other devices.

The processor(s) <NUM> are configured to communicate with devices or controllers <NUM>, such as the first component <NUM> and the second component <NUM> via the one or more communications interfaces <NUM>. In an example, the one or more communications interfaces <NUM> includes a network interface or other interface device, such as the first interface device <NUM> and the second interface device <NUM>, one or more other devices, or any combination thereof.

In conjunction with the described systems and methods, an apparatus for vehicle testing is disclosed that includes means for selecting, at a testing device, a test module that is executable by the testing device to perform, via multiple interface devices, a vulnerability test of one or more components of a vehicle. In some implementations, the means for selecting the test module corresponds to the test controller <NUM>, the testing device <NUM>, the computing device <NUM>, the processor(s) <NUM>, one or more other circuits or devices configured to select a test module, or a combination thereof.

The apparatus also includes means for executing, at the testing device, the test module to perform the vulnerability test, where the vulnerability test includes communicating test data, via one or more of the multiple interface devices, to the one or more components of the vehicle. In some implementations, the means for executing the test module to perform the vulnerability test includes the test controller <NUM>, one or more of the interface devices <NUM>-<NUM>, the testing device <NUM>, the computing device <NUM>, the processor(s) <NUM>, one or more other devices configured to perform the vulnerability test, or a combination thereof.

In some implementations, a non-transitory, computer readable medium stores instructions that, when executed by one or more processors, cause the one or more processors to initiate, perform, or control operations to perform part or all of the functionality described above, e.g. as a computer-implemented method. For example, the instructions may be executable to implement one or more of the operations or methods of <FIG>. In some implementations, part or all of one or more of the operations or methods of <FIG> may be implemented by one or more processors (e.g., one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more digital signal processors (DSPs)) executing instructions, by dedicated hardware circuitry, or any combination thereof.

The illustrations of the examples described herein are intended to provide a general understanding of the structure of the various implementations. Many other implementations may be apparent to those of skill in the art upon reviewing the disclosure. Other implementations may be utilized and derived from the disclosure, such that structural and logical substitutions and changes may be made without departing from the scope of the disclosure. For example, method operations may be performed in a different order than shown in the figures or one or more method operations may be omitted.

Moreover, although specific examples have been illustrated and described herein, it should be appreciated that any subsequent arrangement designed to achieve the same or similar results may be substituted for the specific implementations shown. This disclosure is intended to cover any and all subsequent adaptations or variations of various implementations. Combinations of the above implementations, and other implementations not specifically described herein, will be apparent to those of skill in the art upon reviewing the description.

Claim 1:
A testing device (<NUM>) comprising:
a first interface device (<NUM>) configured to enable communication with a first component (<NUM>) of a vehicle (<NUM>);
a second interface device (<NUM>) configured to enable communication with a second component (<NUM>) of the vehicle (<NUM>);
test module storage (<NUM>) configured to store one or more test modules (<NUM>);
a user interface (<NUM>); and
a test controller (<NUM>) responsive to the user interface (<NUM>) to select a test module (142A) from the test module storage (<NUM>) and to cause the first interface device (<NUM>) to communicate first test data (<NUM>) to the first component (<NUM>) of the vehicle (<NUM>) and to cause the second interface device (<NUM>) to communicate second test data (<NUM>) to the second component (<NUM>) of the vehicle (<NUM>) to perform a cybersecurity vulnerability test (146A) associated with the selected test module (142A),
wherein transmission of the first test data (<NUM>) and the second test data (<NUM>) to the first component (<NUM>) and the second component (<NUM>) of the vehicle (<NUM>), respectively, occurs at least partially overlapping in time, and
wherein an interplay between the first test data (<NUM>) affecting operation of the first component (<NUM>) and the second test data (<NUM>) affecting operation of the second component (<NUM>) indicates whether the first component (<NUM>) and the second components (<NUM>) are vulnerable to a multi-vector cybersecurity attack.