Computerized-system and computerized-method for detecting cyber-attacks on avionic communications of an airborne computerized-device

Abstract

A computerized-system for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, is provided herein. The computerized-system may include a bus-message queue to store bus-avionic-communication-messages transmitted via one or more input buses; an anomaly queue to store anomaly bus-messages; a memory to store the bus-message queue and the anomaly queue; a C-BIT mechanism to operate one or more preconfigured test routines; and one or more processors to operate a rule engine based on a preconfigured ruleset to detect one or more anomalies of bus-avionic-communication-messages for each bus-message in the bus-message queue; The rule engine may be configured to store each bus-message that is detected as an anomaly in the anomaly queue and to send one or more alerts to be presented via one or more external devices for each bus-message in the anomaly queue.

Claims

1. A computerized-system for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, the computerized-system comprising: a bus-message queue to store bus-avionic-communication-messages transmitted via one or more input buses; an anomaly queue to store anomaly bus-messages; a memory to store the bus-message queue and the anomaly queue; a Cyber-Built In Test (C-BIT) mechanism to operate one or more preconfigured test routines; and one or more processors to operate a rule engine based on a preconfigured ruleset to detect one or more anomalies of bus-avionic-communication-messages for each bus-message in the bus-message queue; said rule engine is configured to store each bus-message that is detected as an anomaly in the anomaly queue and send one or more alerts to be presented via one or more external devices for each bus-message in the anomaly queue, wherein the operating of the rule engine comprising of: (i) receiving from the message queue a bus-message having a timestamp and an equipment ID; (ii) operating a timing module to apply timing rules on the received bus-message, based on the received timestamp; (iii) operating a bit-compare module to apply rules on the received message based on data in the message; (iv) operating an Indication Of Compromise (IOC) module to mask and extract data references to detect one or more anomalous dependencies between indicators; and (v) operating a multi-message dependency module, and wherein each bus-message is stored in the bus-message queue after being obtained by one or more input buses based on a configuration setup forwarded to a firmware interpreter and then to a device driver.

2. The computerized-system of claim 1 wherein the entity is at least one of: (i) airbome-electronic-sensor; and (ii) sensor receiving data from an off-board system.

3. The computerized-system of claim 1, wherein the operating of (ii)-(v) is according to a preconfigured order.

4. The computerized-system of claim 1, wherein the firmware interpreter is configured to receive electrical signals from the one or more input buses and to translate the received electrical signals to a raw stream of bus-messages data.

5. The computerized system of claim 1, wherein the device driver is configured to read bus-messages-data from the raw data stream provided by the firmware interpreter and to add to each bus-message: (i) a timestamp; (ii) a bus number; and (iii) equipment ID, according to the one or more input buses that the bus-message has been received.

6. The computerized-system of claim 1, wherein the bus-message queue is configured to operate by a First In First Out (FIFO) technique.

7. The computerized-system of claim 1, wherein the bus-message queue is parallelly tunneling bus-messages to an internal database for offline analysis and to the rule engine, for real-time anomaly detection.

8. The computerized-system of claim 6, wherein the computerized-system is further configured to extract data from the internal database post flight.

9. The computerized-system of claim 6, wherein after a bus-message is evaluated by the rule engine and stored in the internal database, the bus-message is removed from the bus-message queue.

10. The computerized-system of claim 4, wherein each bus message of the bus-messages tunneled from the bus-message queue to the internal database are stored with the bus-message timestamp and the bus number and an equipment ID.

11. The computerized-system of claim 1, wherein the timing module consists of validating at least one of following anomalies: (i) maximum threshold; (ii) message desync; (iii) denial of service; and (iv) invalid message distribution.

12. The computerized-system of claim 1, wherein the bit compare module consists of validating at least one of following anomalies: (i) unknown labels; (ii) unknown equipment IDs; (iii) mismatch mapping of labels to equipment ID; (iv) invalid bitmask; (v) invalid parity bit; (vi) Sign Status Matrix (SSM) failure warning; (vii) invalid data range; and (viii) invalid data continuity.

13. The computerized-system of claim 1, wherein the indicators are bits which vary according to data it represents.

14. The computerized-system of claim 1, wherein the one or more preconfigured test routines include at least one of: (i) timestamp synchronization; (ii) all bits are zero, except parity bit; (iii) flat bit ones; (iv) flat data bit zeros; (v) flat data bit ones; (vi) whitelisted labels; and (vii) data congruity between buses, upper and lower thresholds for data, and timestamp synchronization between buses, in case of redundant buses.

15. The computerized-system of claim 1, wherein the multi-message dependency module comprising comparing between bus-messages of redundant systems to check that bus-messages of same type that have been sent during same period equals to or exceeds one or more preconfigured thresholds.

16. A computerized-method for anomaly detection of Point-to-Point avionic conummication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, the computerized-method comprising: using C-BIT mechanism to operate one or more preconfigured test routines; operating a rule engine based on a preconfigured ruleset to detect one or more anomalies of bus-avionic-communication-messages for each bus-message in the bus-message queue; storing each bus-message that is detected by the rule engine as anomaly in an anomaly queue; and sending one or more alerts to be presented via one or more external devices for each bus-message in the anomaly queue, wherein the operating of the rule engine comprising of: (i) receiving from the message queue a bus-message having a timestamp and an equipment ID; (ii) operating a timing module to apply timing rules on the received bus-message, based on the received timestamp; (iii) operating a bit-compare module to apply rules on the received message based on data in the message; (iv) operating an Indication Of Compromise (IOC) module to mask and extract data references to detect one or more anomalous dependencies between indicators; and (v) operating a multi-message dependency module, and wherein each bus-message is stored in the bus-message queue after being obtained by one or more input buses based on a configuration setup forwarded to a firmware interpreter and then to a device driver.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) In order for the present disclosure, to be better understood and for its practical applications to be appreciated, the following Figures are provided and referenced hereafter. It should be noted that the Figures are given as examples only and in no way limit the scope of the disclosure. Like components are denoted by like reference numerals.

(2) FIG. 1 schematically illustrates a high-level diagram of a computerized-system for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, in accordance with some embodiments of the present disclosure;

(3) FIGS. 2A-2B illustrate a computerized-system for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, in accordance with some embodiments of the present disclosure; and

(4) FIG. 3 is a schematic flowchart of a computerized-method for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, in accordance with some embodiments of the present disclosure.

DETAILED DESCRIPTION

(5) In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the disclosure. However, it will be understood by those of ordinary skill in the art that the disclosure may be practiced without these specific details. In other instances, well-known methods, procedures, components, modules, units and/or circuits have not been described in detail so as not to obscure the disclosure.

(6) Although embodiments of the disclosure are not limited in this regard, discussions utilizing terms such as, for example, “processing,” “computing,” “calculating,” “determining,” “establishing”, “analyzing”, “checking”, or the like, may refer to operation(s) and/or process(es) of a computer, a computing platform, a computing system, or other electronic computing device, that manipulates and/or transforms data represented as physical (e.g., electronic) quantities within the computer's registers and/or memories into other data similarly represented as physical quantities within the computer's registers and/or memories or other information non-transitory storage medium (e.g., a memory) that may store instructions to perform operations and/or processes. Although embodiments of the disclosure are not limited in this regard, the terms “plurality” and “a plurality” as used herein may include, for example, “multiple” or “two or more”. The terms “plurality” or “a plurality” may be used throughout the specification to describe two or more components, devices, elements, units, parameters, or the like. Unless explicitly stated, the method embodiments described herein are not constrained to a particular order or sequence. Additionally, some of the described method embodiments or elements thereof can occur or be performed simultaneously, at the same point in time, or concurrently. Unless otherwise indicated, use of the conjunction “or” as used herein is to be understood as inclusive (any or all of the stated options).

(7) In computer architecture, a bus is a communication system that transfers data between components inside a computer, or between computers. Existing Control Area Network (CAN) bus solutions in vehicles may not be a good fit to be deployed in aircrafts due to different network protocol usage in aircrafts.

(8) Other existing ground-based systems are designed to work on large scale networks which are running various network protocols, however, they require additional power, add additional weight, increase costs, and require additional space which are all limited in an aircraft.

(9) Therefore, there is a need for a technical solution that will address cyber-attacks deployed on avionic communications of commercial and private jet aircraft by monitoring a subset of avionic communications and detecting anomalies.

(10) Furthermore, there is a need for a system and method for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity, such as an airborne-electronic-sensor or a sensor receiving data from an off-board system, i.e., ground operations (Ops) to one or more aircraft-systems in an aircraft during phases of flight, which will be dedicated to ARNIC 429 protocol.

(11) FIG. 1 schematically illustrates a high-level diagram of a computerized-system 100 for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, in accordance with some embodiments of the present disclosure.

(12) According to some embodiments of the present disclosure, a system, such as computerized-system 100 for anomaly detection of Point-to-Point avionic communication messages, via a message-bus between an entity, such as an airborne-electronic-sensor or a sensor receiving data from an off-board system to one or more aircraft-systems in an aircraft during phases of flight, may be an airborne device for monitoring and cyber anomaly detection of avionics communications. The phases of flight may be pre departure, take-off run, take-off flight phase, descending, landing and approach.

(13) According to some embodiments of the present disclosure, the computerized-system 100 may be based on a Commercial Of The Shelf (COTS) that is airborne certified and may include the required input buses 110, e.g., Aeronautical Radio Incorporated (ARNIC) 429 channels and output standard channels 130, such as standard Universal Serial Bus (USB) or Ethernet channels for maintenance laptop connection.

(14) According to some embodiments of the present disclosure, the output channels 130 may include capability to transmit data to external interfaces 140, such as ground ops via standard Very High Frequency (VHF) or other radio frequency connectivity, cockpit's printer, Electronic Flight Bag (EFB) and a screen 150, such as Liquid-Crystal Display (LCD) screen connected to the device 120 itself

(15) According to some embodiments of the present disclosure, the device 120 may provide Intrusion Detection System (IDS) only, by monitoring the data buses and alerting of any anomalies found. Thus, the pilot may not rely on the information provided by the system and may or may not act according to Quick Reference Handbook (QRH), i.e., a checklist routine defined by the regulator.

(16) According to some embodiments of the present disclosure, since the device 120 is a listener only on the input buses 110, the device 120 may not transmit any data, command, or other pulses on the avionic internal buses.

(17) FIG. 2A illustrates a computerized-system 200A for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, in accordance with some embodiments of the present disclosure. The entity may be an airborne electronic sensor or a sensor receiving data from an off-board system.

(18) According to some embodiments of the present disclosure, system 200A may implement a computerized method, such as computerized-method 300 for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight.

(19) According to some embodiments of the present disclosure, a procedure, such as Cyber-Build-In-Test (C-BIT) mechanism 245a may be running during the first load of the system 200A for a predefined timeframe. The purpose of the C-BIT mechanism 245a may be to validate a preconfigured subset of possible anomalies before running a full diagnostic, by a rule engine, such as rule engine 255a, in order to rule out monitored devices or systems compromise prior to loading the system 200A.

(20) According to some embodiments of the present disclosure, the C-BIT mechanism 245a, may also operate one or more preconfigured test routines. One or more processors 225a may operate a rule engine 255a based on a preconfigured ruleset, such as ruleset 250a to detect one or more anomalies of bus-avionic-communication-messages for each bus-message in the bus-message queue 235a.

(21) According to some embodiments of the present disclosure, the bus-message queue 235a and the anomaly queue 260a may be stored in memory 205a. The bus-message queue 235a may be implemented as a First In First Out (FIFO) queue that stores all the bus-messages that have been transmitted on the one or more input buses 215a.

(22) According to some embodiments of the present disclosure, the one or more preconfigured test routines may include at least one of: timestamp synchronization; all bits are zero, except parity bit; flat bit ones; flat data bits zeros; flat data bits ones; whitelisted labels; and data congruity between buses, upper and lower thresholds for data, and timestamp synchronization between buses, in case of redundant buses.

(23) According to some embodiments of the present disclosure, the rule engine 255a may be configured to store each bus-message that is detected as an anomaly in the anomaly queue 260a for real-time anomaly detection and send one or more alerts to be presented via one or more external devices 265a for each bus-message in the anomaly queue 260a.

(24) According to some embodiments of the present disclosure, the ruleset 250a may be an input of the rule engine 255a which may contain a wide range of cyber rules to apply to each bus-message of the bus-messages which are transmitted on the one or more input buses 215a. The ruleset 250a may be adjusted to include a different set of rules, for each aircraft type and for each tail number, i.e., an alphanumeric code between two and six characters in length used to identify a specific airplane.

(25) According to some embodiments of the present disclosure, the rules which are preconfigured to be included in the ruleset 250a may be determined by the aircraft tail number system spec, network, devices, and additional information that may vary between aircrafts. During 20-40 years of service, each aircraft gets maintenance, upgraded devices, and sometimes downgraded. There may be differences between devices of identical aircraft models, but the aircraft tail number may differ.

(26) According to some embodiments of the present disclosure, the ruleset 250a may be updated from time to time, during standard post flight system updates. Changes to the ruleset 250a during flight may not be permitted and it may be denied.

(27) According to some embodiments of the present disclosure, the ruleset 250a may be implemented as an encrypted binary file that may be loaded once on system load procedure or after a system restart.

(28) According to some embodiments of the present disclosure, the rule engine 255a may be a heuristic, algorithm-based engine that makes real-time, ‘thumb-ruling’ decisions, based on the spec of the ruleset 250a. By the setup specified in internal modules of the rule engine 255a, each bus-message of the bus-messages may be processed and searched for anomalies. Once an anomaly is found in any of the internal modules, the anomalous message may be pushed to an anomaly queue 260a and the rule engine 255a may continue to process the next bus-message.

(29) According to some embodiments of the present disclosure, the operating of the rule engine 255a may include the following internal modules: (i) receiving from the message queue a bus-message having a timestamp and an equipment ID; (ii) operating a timing module to apply timing rules on the received bus-message, based on the received timestamp; (iii) operating a bit-compare module to apply rules on the received message based on data in the message; (iv) operating an Indication Of Compromise (IOC) module to mask and extract data references to detect one or more anomalous dependencies between indicators; and (v) operating a multi-message dependency module.

(30) According to some embodiments of the present disclosure, the equipment ID provides a way to differentiate between identical messages, identical labels and similar data in redundant systems, like left and right gears. For example, when using Pitot sensors, each pilot, the captain and the co-pilot, have a different sensor which is a transmitter, handling similar data, on different buses, to provide the required redundancy.

(31) According to some embodiments of the present disclosure, the operating of operations (ii)-(v) may be performed according to a preconfigured order.

(32) According to some embodiments of the present disclosure, the anomaly queue 260a may be a message alerting FIFO queue. Once an anomaly is detected, the anomalous message may be added to the anomaly queue 260a. Anomalous messages may be found during the operation of the C-BIT mechanism 245a, which is the device load and up to a predefined time frame, or while bus-messages are being evaluated in the rule engine 255a with accordance definitions of the ruleset 250a.

(33) According to some embodiments of the present disclosure, according to a predetermined configuration, bus-messages may be tunneled to one or more external devices 265b. Once the oldest bus-message is tunneled, it may be popped out from the anomaly 260b.

(34) According to some embodiments of the present disclosure, a bit modification may occur which might indicate of a cyber-attack. The modification may be detected by a timing module, such as timing module 280b in FIG. 2B.

(35) FIG. 2B illustrates a computerized-system 200B for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, in accordance with some embodiments of the present disclosure.

(36) According to some embodiments of the present disclosure, system 200B may include the components of system 200A in FIG. 2A. The entity may be an airborne electronic sensor or a sensor receiving data from an off-board system.

(37) According to some embodiments of the present disclosure, system 200B may be implemented as a device which is based on a Commercial Off the Shelf (COTS) that is airborne certified and contains input channels such as ARINC-429 input channels and output standard channels, such as standard USB/Ethernet channels for maintenance laptop connection.

(38) Aeronautical Radio Incorporated (ARINC)-429 is a technical standard for the predominant avionics data bus used on commercial and transport aircraft. It defines the physical and electrical interfaces of a two-wire data bus and a data protocol to support an aircraft's avionics local area network. Data words are 32 bits in length and most messages consist of a single data word. Messages are transmitted at either 12.5 or 100 kbit/s to other system elements that are monitoring the bus messages. The transmitter constantly transmits either 32-bit data words or the NULL state (0 Volts). The protocol allows for self-clocking at the receiver end, thus eliminating the need to transmit clocking data.

(39) According to some embodiments of the present disclosure, a configuration setup 210b may determine data that may enter to one or more input buses 215b, numbered as ‘1’through ‘N’. The one or more input buses 215b are the physical layer that carries electronic signals, within the avionics domain, e.g., cockpit. The input buses 215b may deliver data from one or more sensors to one or more computerized systems to assist in flying the aircraft, according to an ARINC protocol, e.g., ARINC-429.

(40) According to some embodiments of the present disclosure, the one or more sensors may be for example, control sensors such as tachometer, engine temperature gauge, fuel- and oil-quantity gauge, pressure gauge, altimeter, airspeed-measurement, vertical speed indicators and others supply additional signals to cockpit indicators, which are informing the pilots to act or to be precautious. The information may be received from one sensor by several systems and presented to the pilots by a display unit that may be associated to one of the systems, such as, flight control systems, landing gear, hydraulic systems, engine bleed air system, fuel systems and the like.

(41) According to some embodiments of the present disclosure, the input buses 215b to the device can range from a single bus to ‘N’ parallel buses, e.g., 16 parallel buses. The one or more sensors that transmits data to the system 200B may be for example, point to point communicators or redundant transmitters, transmitting from left and right in parallel.

(42) According to some embodiments of the present disclosure, the firmware interpreter 220b may translate electrical signals to a raw stream of data which may be forwarded to a device driver 230b. The bus-message is physically transmitted on the bus and then may be interpreted by the firmware interpreter 220b in the firmware layer and then translated to bits in the device driver 230b.

(43) According to some embodiments of the present disclosure, the device driver 230b may read data from the raw data stream provided by the firmware interpreter 220b, commonly in chunks of 32 bits based on the ARINC protocol that is being used. The device driver 230b also adds to the bus-message a timestamp of a received bus-message and a bus indication according e.g., bus number, according to the input bus of the input buses 215b and also the equipment ID of the transmitting system.

(44) According to some embodiments of the present disclosure, a bus-messages may be tunneled in parallel to the bus-message queue 235b for later on storage on the internal database 240b and offline analysis. The bus-message is physically transmitted on the bus, which is a physical layer.

(45) According to some embodiments of the present disclosure, after a bus-message is evaluated by the rule engine 255b and stored in a database, such as the internal database 240b, the bus-message may be removed from the bus-message queue 235b.

(46) According to some embodiments of the present disclosure, each queued bus-message may be tunneled in parallel into the internal database 240b, in order to store all the raw data on the one or more input buses 215b and into the rule engine 255b in order to evaluate the messages against a preconfigured ruleset, such as ruleset 250b. Once a bus-message is stored in the internal database 240b and evaluated by the rule engine 255b, it may be popped out from the bus-message queue 235b.

(47) According to some embodiments of the present disclosure, since each message in the anomaly queue 260b may be also stored in the internal database 240b an anomaly update 270b process may find a relevant bus-message and may update the anomaly found and recorded in the anomaly queue 260b.

(48) According to some embodiments of the present disclosure, the internal database 240b may store all the bus-messages that have been transmitted on the one or more input buses 215b with the added data of timestamp of transmission, a bus number, i.e., on which input bus out of the one or more input buses 215a, each bus-message has been transmitted on and an equipment ID.

(49) According to some embodiments of the present disclosure, all the bus-messages in the anomaly queue 260b may be messages containing anomaly data, and so, each message anomaly may be updated in the internal database 240b using an anomaly update 270b process and later on tunneled to the configured external interfaces 265b.

(50) According to some embodiments of the present disclosure, data may be extracted from the internal database 240b post flight for further analysis.

(51) According to some embodiments of the present disclosure, post flight data extract 275b may be conducted once the aircraft is at jet bridge, i.e., air gate, connected to the airport's gate link or at other types of standard service connection, such as maintenance laptop. The data stored may be downloaded in a secured manner for ground-ops analysis.

(52) According to some embodiments of the present disclosure, rule engine 255b may include a timing module 280b. The timing module 280b may apply preconfigured rules which are based on the timestamps of the bus-messages, which reflect when the bus-message was sent from the sensor. The timing rules of the timing module 280b may validate at least one of the following anomalies: maximum threshold, message de-sync, denial of service and invalid message distribution. For example, when label 0×15 is expected to arrive every 50 ms, and the maximum time threshold is defined as 51 ms, the timing module 280b may check, a gap between two messages with label 0×15 and if the gap is a 70 ms gap, the timing module 280b may send an alert as to a cyber-attack.

(53) According to some embodiments of the present disclosure, rule engine 255b may also include a bit-compare module 295b. The bit-compare module 295b may apply rules which are based on the actual data being sent in the message. The bit-compare rules of the bit compare module 295b may validate at least one of the following anomalies: unknown labels, unknown equipment IDs, mismatch mapping of labels to equipment ID, invalid bitmask, invalid parity bit, SSM failure warnings, invalid data range, invalid data continuity.

(54) For example, the bit-compare module 295b may send an alert when there when a rule related to an invalid bitmask is being violated. An invalid bitmask rule may be violated, when a bit is activated when it is not supposed to be activated, according to ARNIC 429 specification, e.g., since the bit is reserved, not used, padding and the like.

(55) According to some embodiments of the present disclosure, the bit-compare module 295b may identify for example, a sensor of the fuel system may transmit data as to increased amount of fuel after the aircraft is in the air for a certain amount of time.

(56) According to some embodiments of the present disclosure, rule engine 255b may also include an Indication Of Compromise (IOC) module 290b. The IOC module 290b may be an algorithm-based module, handling of masking and extracting different data references in order to detect possible anomalous dependencies between different indicators. The indicators are specific bits that vary between different data it represents. For example, wind speed indicators will rely on different bit sets than altitude indicators.

(57) According to some embodiments of the present disclosure, the IOC module 290b may be implemented by Artificial Intelligence (AI) techniques, such as machine learning modules or deep learning models which use artificial neural networks.

(58) According to some embodiments of the present disclosure, commonly each pilot system is accompanied with a co-pilot system, each having a different equipment ID. From time to time the two systems may not present the same information with regards to the same situation. The difference between the presented information may be due to an error or due to a cyber-attack. Therefore, the rule engine 255b may also include a multi message dependency module 285b. For redundant systems or devices, such as left/right pilot sensors, the multi dependency module 285b may compare reported data to preconfigured thresholds and may distinguish between the redundant systems by their equipment ID. For example, label 0×16 should be transmitted twice in a second, from the Pitot sensor, equipment ID left and from the Pitot sensor equipment ID right. If the right Pitot sensor transmitted once in a second, and the left Pitot sensor transmitted twice, the right Pitot sensor is suspected based on the equipment ID, to be under attack.

(59) According to some embodiments of the present disclosure, the multi dependency module 285b may compare between bus-messages of redundant systems to check that bus-messages of similar type that have been sent during same period equals to or exceeds one or more preconfigured thresholds. Meaning, in a situation where there is a difference between information in the pilot system and the co-pilot system, the difference may be up to the preconfigured threshold before an alert may be sent as to cyber-attack.

(60) FIG. 3 is a schematic flowchart of a computerized-method 300 for anomaly detection of Point-to-Point avionic communication messages via a message-bus between an entity to one or more aircraft-systems in an aircraft during phases of flight, in accordance with some embodiments of the present disclosure. The entity may be an airborne electronic sensor or a sensor receiving data from an off-board system.

(61) According to some embodiments of the present disclosure, operation 310 may comprise using C-BIT mechanism to operate one or more preconfigured test routines. The C-BIT mechanism may be a C-BIT mechanism such as C-BIT 245a in FIG. 2A and C-BIT 245b in FIG. 2B.

(62) According to some embodiments of the present disclosure, operation 320 may comprise operating a rule engine based on a preconfigured ruleset to detect one or more anomalies of bus-avionic-communication-messages for each bus-message in the bus-message queue. The rule engine may be a rule engine such as rule engine 255a in FIG. 2A and rule engine 255b in FIG. 2B. The bus-message queue may be bus-message queue 235a in FIG. 2A and bus-message queue 235b in FIG. 235b in FIG. 2B.

(63) According to some embodiments of the present disclosure, operation 330 may comprise storing each bus-message that is detected by the rule engine as anomaly in an anomaly queue. The anomaly queue may be a queue, such as anomaly queue 260a in FIG. 2A and anomaly queue 260b in FIG. 2B.

(64) According to some embodiments of the present disclosure, sending one or more alerts to be presented via one or more external devices for each bus-message in the anomaly queue. The alerts may be related to cyber-attack. For example, the alerts may include timestamp, equipment ID, bus ID, label and attack key. It may also include, when configured to, an attack description elaborating the attack type

(65) It should be understood with respect to any flowchart referenced herein that the division of the illustrated method into discrete operations represented by blocks of the flowchart has been selected for convenience and clarity only. Alternative division of the illustrated method into discrete operations is possible with equivalent results. Such alternative division of the illustrated method into discrete operations should be understood as representing other embodiments of the illustrated method.

(66) Similarly, it should be understood that, unless indicated otherwise, the illustrated order of execution of the operations represented by blocks of any flowchart referenced herein has been selected for convenience and clarity only. Operations of the illustrated method may be executed in an alternative order, or concurrently, with equivalent results. Such reordering of operations of the illustrated method should be understood as representing other embodiments of the illustrated method.

(67) Different embodiments are disclosed herein. Features of certain embodiments may be combined with features of other embodiments; thus, certain embodiments may be combinations of features of multiple embodiments. The foregoing description of the embodiments of the disclosure has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed. It should be appreciated by persons skilled in the art that many modifications, variations, substitutions, changes, and equivalents are possible in light of the above teaching. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the disclosure.

(68) While certain features of the disclosure have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those of ordinary skill in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the disclosure.