Systems and procedures for improving and updating an IDS with fuzzing results

Abstract

A method for operating an IDS for a device comprises performing a fuzzing operation on a software program running on a system under test, wherein the software program corresponds to a provided software program on the device monitored by the IDS and the system under test is designed to emulate at least one system of the device, wherein the fuzzing operation comprises supplying fuzzing inputs to the software program, monitoring outputs of the software program, and detecting, based on the outputs, a vulnerability for attacks in the software program caused by supplying the fuzzing inputs to the software program.The procedure further includes generating and storing a vulnerability entry corresponding to the detected vulnerability, wherein the vulnerability entry contains information for identifying the detected vulnerability, and updating, based on the vulnerability entry, at least one component of the IDS and a code section of the provided software program.

Description

Technical FieldThe present disclosure relates to attack detection systems (IDSs) for in-vehicle and off-vehicle networks.BackgroundThe background description provided herein is for the purpose of generally presenting the context of the disclosure. The work of the present inventors, as described in this background section, as well as aspects of the description that may not be considered prior art at the time of filing, are neither expressly nor implicitly recognized as prior art over the present disclosure.Vehicles such as cars, trucks, sport utility vehicles, crossovers, minivans, or other suitable vehicles include a propulsion system, a braking system, a steering system, and the like. Such vehicle systems may be manually controlled (e.g., by a vehicle operator) and / or autonomously or semi-autonomously controlled (e.g., by one or more autonomous or semi-autonomous vehicle controllers). In some examples, autonomous or semi-autonomous vehicle controllers rely on or use different machine learning models for decision making in vehicle control.A CAN (controller area network) bus is the central communication network in various modern systems, such as automotive systems, aerospace systems, industrial systems, etc. Some of the nodes of the CAN bus and more generally the internal network of the vehicle may be equipped with remote interfaces. Such interfaces may be frequently used to enable wireless updates, offer additional services, measure application usage, and measure the use of certain functions in the ECU to enable service services, etc.Vehicles may have systems that can detect attacks (e.g., cyber security attacks), sometimes also referred to as intrusion detection systems ("IDS"). The automotive system of modern vehicles may be equipped with a large number of electronic control units (ECUs) connected via a network using CAN, automotive Ethernet, or other network technology. These ECUs can control the vehicle by executing more and more complex software. Moreover, network connectivity has further increased due to sensor data, such as camera streams or LIDAR. The resulting automotive system can become an increasingly attractive goal for attackers who are interested in compromised this system. The IDS aims to detect attacks and may collect various types of automobile data to verify consistency and ensure the integrity of network traffic as well as command and control functions. Current IDS solutions send such data to a cloud backend for further processing.SummaryA method of operating an attack detection system (IDS) for a device comprises performing a fuzzing operation on a software program executed on a system to be tested, the software program corresponding to a provided software program on the device monitored by the IDS, and the system to be tested configured to emulate at least one system of the device, the fuzzing operation comprising supplying fuzzing inputs to the software program, monitoring outputs of the software program during execution on the system to be tested, and detecting, based on the outputs, a weak point for attacks in the software program caused by the supplying of the fuzzing inputs to the software program. The method further includes generating and storing a vulnerabilities entry corresponding to the detected vulnerabilities, the vulnerabilities entry including information for identifying the detected vulnerabilities, and updating, based on the vulnerabilities entry, at least one of a component of the IDS and a code portion of the provided software program.In other features, supplying the fuzz inputs includes providing fuzz inputs configured to cause errors in at least one of a plurality of code portions of the software program. Generating and storing the vulnerary entry includes storing the vulnerary in a vulnerary database. The vulnerabilities entry includes at least one of a software version of the software program, a hardware version emulated by the system under test executing the software program, a time and date the vulnerabilities were detected, the supplied fuzz inputs, an identification of a remedy for the detected vulnerabilities, and a hash of one or more values included in the vulnerabilities entry. The method further includes determining whether the detected vulnerabilities correspond to a vulnerabilities for attacks for the provided software program monitored by the IDS by at least one of determining whether a software version of the software program corresponds to a software version of the provided software program, and determining whether the software version of the software program temporally precedes the software version of the provided software program.In other features, the updating includes at least one of performing at least one correction operation on the software program and updating the provided software program on the device based on the at least one correction operation, and modifying a configuration of the software program. The method further includes comparing the vulnerabilities entry to previously detected vulnerabilities and storing the vulnerabilities entry in a vulnerabilities database in response to a determination that the vulnerabilities entry does not correspond to any of the previously detected vulnerabilities. The method further includes at least one of generating an alarm in response to detecting the weak spot and generating instructions to a user of the device in response to detecting the weak spot. The method further includes, in response to detecting the vulnerabilities, generating a fingerprint associated with an operating characteristic of the system under test during detection of the vulnerabilities, and updating the IDS based on the fingerprint. The method further includes detecting, by the IDS, an attack on the device, supplying fuzz inputs to the software program based on the detected attack on the device, updating at least one of the component of the IDS and the code portion of the provided software program based on the performance of the software program in response to the fuzz inputs.An attack detection system (IDS) includes a fuzzing system configured to perform a fuzzing operation on a software program executed on a system under test, the software program corresponding to a provided software program on a device monitored by the IDS, and the system under test configured to emulate at least one system of the device. To perform the fuzzing operation, the fuzzing system is configured to provide fuzzing inputs to the software program and monitor outputs of the software program as it executes on the system under test. A test controller is configured to identify a vulnerabilities for attacks in the software program caused by the delivery of the fuzzing inputs to the software program based on the outputs, and generate and transmit a vulnerabilities entry corresponding to the identified vulnerabilities to a vulnerabilities database, the vulnerabilities entry including information identifying the identified vulnerabilities.In other features, the IDS further includes the vulnerabilities database. The IDS further includes a security operation center configured to update at least one of a component of the IDS and a code portion of the provided software program based on the vulnerabilities entry. To provide the fuzz inputs, the fuzz system provides fuzz inputs configured to cause errors in at least one of a plurality of code portions of the software program. The vulnerabilities entry includes at least one of a software version of the software program, a hardware version emulated by the system under test executing the software program, a time and date at which the vulnerabilities were detected, the supplied fuzz inputs, an identification of a remedy for the detected vulnerabilities, and a hash of one or more values included in the vulnerabilities entry. The IDS further comprises the system under test.In other features, at least one / one of the test controller and a component of a security operations center is configured to determine whether the detected vulnerabilities correspond to a vulnerabilities for attacks for the provided software program monitored by the IDS, by at least one of determining whether a software version of the software program corresponds to a software version of the provided software program, and determining whether the software version of the software program temporally precedes the software version of the provided software program. At least one / one of the test controller and the component of the VSOC is configured to, in response to detecting the vulnerabilities, perform at least one correction operation on the software program, generate, during the detection of the vulnerabilities, a fingerprint associated with an operating characteristic of the system under test, update the IDS based on the fingerprint, and (iv) update the provided software program on the device based on the at least one correction operation. The IDS further includes a security operations center configured to compare the vulnerabilities entry to previously detected vulnerabilities and store the vulnerabilities entry in the vulnerabilities database, in response to a determination that the vulnerabilities entry does not correspond to any of the previously detected vulnerabilities, and, in response to the detection of the vulnerabilities, generate an alarm, and, in response to the detection of the vulnerabilities, generate instructions to a user of the device.A computing device configured to implement at least a portion of an attack detection system (IDS) includes a processing device configured to execute instructions stored in memory to cause the IDS to perform a fuzzing operation on a software program executed on a system under test. The software program corresponds to a provided software program on a vehicle device monitored by the IDS, and the system under test is configured to emulate at least one system of the device. The fuzzing operation includes supplying fuzzing inputs to the software program, monitoring outputs of the software program during execution on the system under test, and detecting, based on the outputs, a vulnerabilities for attacks in the software program caused by the supplying of the fuzzing inputs to the software program. The processing device is further configured to execute the instructions to generate a vulnerabilities entry corresponding to the detected vulnerabilities, the vulnerabilities entry including information identifying the detected vulnerabilities, determine whether the vulnerabilities entry matches previously detected vulnerabilities associated with the software program, store the vulnerabilities entry in a vulnerabilities database when it is determined that the vulnerabilities entry does not correspond to any of the previously detected vulnerabilities, and update, based on the vulnerabilities entry, at least one of a component of the IDS and a code portion of the provided software program.Further areas of applicability of the present disclosure will become apparent from the detailed description, claims and drawings. The detailed description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the disclosure.Brief Description of the DrawingsFIG. 1 is an example of a computing device according to the present disclosure. FIG. 2 is an example system, and a vehicle implementing an attack detection system (IDS) according to the present disclosure. FIG. 3 shows steps of an example method for identifying a weak spot in an IDS of a vehicle according to the present disclosure. FIG. 4 shows steps of an example method for performing correction operations in response to identifying a weak spot in an IDS of a vehicle, in accordance with the present disclosure. FIG. 5 shows a schematic diagram of interaction between a computer controlled machine and a control system according to the principles of the present disclosure. FIG. 6 shows a schematic diagram of the control system of FIG. 5 configured to control a vehicle, which may be a partially autonomous vehicle, a fully autonomous vehicle, a partially autonomous robot, or a fully autonomous robot, in accordance with the principles of the present disclosure. FIG. 7 shows a schematic diagram of the control system of FIG. 5 configured to control a manufacturing machine, such as a punch cutter, a milling cutter, or a downhole drill, of a manufacturing system, such as part of a production line. FIG. 8 shows a schematic diagram of the control system of FIG. 5 configured to control a power tool having an at least partially autonomous mode, such as a drilling machine or a driver. FIG. 9 shows a schematic diagram of the control system of FIG. 5 configured to control an automated personal assistant. FIG. 10 shows a schematic diagram of the control system of FIG. 5 configured to control a monitoring system, for example an access control system or an observation system. FIG. 11 shows a schematic diagram of the control system of FIG. 5 configured to control an imaging system, for example, an MRI apparatus, an X-ray imaging apparatus, or an ultrasound apparatus.In the drawings, reference numerals may be reused to identify similar and / or identical elements.DETAILED DESCRIPTIONEmbodiments of the present disclosure are described herein. It should be understood, however, that the disclosed embodiments are merely examples and other embodiments may take various and alternative forms. The figures are not necessarily to scale; some features could be exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the embodiments. As those skilled in the art will understand, various features illustrated and described with reference to one of the figures may be combined with features illustrated in one or more other figures to produce embodiments that are not explicitly illustrated or described. The combinations of features illustrated provide representative embodiments for typical applications. However, various combinations and modifications of the features consistent with the teachings of this disclosure could be desired for particular applications or implementations.In-vehicle networks may be prone to malicious attacks / intrusion attempts due to the large number of electrical control devices (ECUs), connectivity of the ECUs to external networks, increasing dependence of the ECUs on software, etc. Detecting attacks on networks is an integral part of vehicle safety in order to prevent or at least reduce the effects of such attacks. Various methods may be implemented to improve vehicle safety including, but not limited to, firewalls, white lists, black lists of messages, and dedicated attack detection systems (IDSs) implemented on one or more of the ECUs (e.g., gateway ECUs). An IDS is a system that monitors predefined systems and / or networks and identifies intrusion attempts based on detection of suspect, malicious, or undefined system behavior. The operation of the IDS is based on the prerequisite that the intrusion attempt differs markedly from the normal system behavior. The IDS types include, but are not limited to, host-based IDS, network IDS, distributed IDS, rule-based IDS, IDS based on machine learning or deep learning, etc.Rule-based schemes and algorithms of IDS are not normally designed to accurately identify attacks that were not previously identified. IDS and IDS methods according to the present disclosure implement fuzzing systems and techniques to accurately detect attacks that have not been previously identified (i.e., attacks for which there are not yet any existing rule-based detection criteria within the IDS).In fuzzing systems, specially designed inputs (or stimuli) are provided to a particular software program to be tested. These stimuli are designed to excite a particular path of the program that causes a weak point when executed. For example, the stimuli are designed to mimic invalid or semi-valid, unexpected, or random data that may cause software or system crashes, erroneous outputs, memory leaks, or other errors. Although "invalid", the stimuli may be similar to valid inputs so that the stimuli are not rejected by the system first, but continue to cause errors within a processing chain. Accordingly, the stimuli facilitate the identification of a security-hazardous code section. The vulnerable code may then be changed / corrected and the fuzzing process is iteratively repeated / executed (e.g., by developing software, testing, fuzzing (creating and entering stimuli), finding, repairing, providing on the system, etc.). Because systems according to the present disclosure are configured to implement IDS, fuzzing (e.g., continuous and iterative based fuzz), and combinations thereof, new vulnerabilities may be identified and corrected. Although described herein with reference to "vulnerabilities", the principles of the present disclosure may also be applied to detect other types of performance issues or anomalies, errors, etc.In some examples, IDSs and IDS methods according to the present disclosure are further configured to implement fingerprinting techniques to detect proper execution of a program under test, deviations from "normal" execution, etc. For example, during a profiling phase, different operating characteristics (e.g., power consumption (R) as a function of a measured voltage V) are measured / recorded and assigned to corresponding individual software tasks. Accordingly, performance measurements for each individual software task as well as a series of performance measurements for an entire scheduling cycle (e.g., all software tasks) may be obtained and stored (e.g., as a power consumption profile). This profiling may be repeated multiple times to calculate an average for each measurement (e.g., to reduce the effects of outliers, noise, etc.).During an operation phase, operating characteristics (e.g., current consumption values) are observed / measured and compared to the stored current consumption profile derived in a previous phase. In one example, a deviation is obtained between the observed power consumption for a particular task and the stored power consumption for that task (i.e., the stored power consumption profile). For example, a root mean square may be used to calculate the deviation and obtain a positive value. A deviation greater than a first threshold (e.g., T 1) for the corresponding software task may be indicative of an anomaly.In another example, a deviation is obtained between the observed power consumption for multiple tasks (e.g., a trace having a full list of software tasks) and the stored power consumption for the multiple tasks (e.g., using a root mean square calculation). A deviation greater than a second threshold (e.g., T 2) for the plurality of software tasks may be indicative of an anomaly.In another example, the observed power consumption may be compared to the stored power consumption profile using a model (e.g., a Markov chain based model, a probability based Bayesian method, etc.). In this way, the observed behavior of actual measurements over time may be compared to stored values, rather than comparing only individual values.FIG. 1 shows a block diagram of an example computing device 100 configured to implement the IDS and IDS method, in accordance with some embodiments of the disclosure. Computing device 100 may include a controller 105, which may be, for example, a central processing unit (CPU), a chip or any suitable computing or computing device, an operating system 115, memory 120, executable code 125, a storage server system 130, input devices 135, and output devices 140. The controller 105 (or one or more controllers or processors, possibly distributed across multiple units or devices) may be configured to perform the methods described herein and / or function as the various modules, units, etc. According to embodiments of the disclosure, a plurality of the computing devices 100 may be included in a system, and one or more of the computing devices 100 may function as components of a system.The operating system 115 may be or include any code segment (e.g., one similar to executable code 125 described herein) designed and / or configured to perform tasks that include coordinating, planning, deciding, monitoring, controlling, or otherwise managing the operation of the computing device 100, such as planning execution of software programs or tasks, or enabling communication between software programs or other hardware modules or units. The operating system 115 may be a commercial operating system. Note that operating system 115 may be an optional component, e.g., in some embodiments, a system may include a computing device that does not require or include operating system 115. For example, a computer system may be or include a microcontroller, an application specific circuit (ASIC), a field programmable array (FPGA), a network controller (e.g., a CAN bus controller), an associated transceiver, a system on a chip (SOC), and / or any combination thereof that may be used without an operating system.The memory 120 may be or include, for example, random access memory (RAM), read only memory (ROM), dynamic RAM (DRAM), synchronous DRAM (SD-RAM), double data rate memory chip (DDR), flash memory, volatile memory, nonvolatile memory, cache memory, buffer, short term storage unit, long term storage unit, or other suitable memory or mass storage units. The working memory 120 may be or comprise a plurality of possibly different storage units. The memory 120 may be a non-transitory computer- or processor-readable medium, or a non-transitory computer storage medium, e.g., RAM.Executable code 125 may be any executable code, e.g., an application, program, process, task, or script. Executable code 125 may be executed by controller 105 under control of operating system 115. For example, executable code 125 may be an application that forces security in a vehicle, such as further described herein, detecting or preventing cyber attacks on in-vehicle networks. Although a single element of executable code 125 is shown in FIG. 1 for clarity, a system according to some embodiments of the disclosure may include a plurality of executable code segments similar to executable code 125 that may be loaded into memory 120 and cause controller 105 to perform methods described herein. Where appropriate, the terms "process" and "executable code" may mean the same herein and be used interchangeably. For example, the verification, validation, and / or authentication of a process may mean the verification, validation, and / or authentication of executable code.The storage system 130 may be or include, for example, flash memory as known in the art, memory incorporated or embedded in a microcontroller or chip as known in the art, a hard disk drive, a CD-R (recordable CD) drive, a Blu-ray disk (BD), a USB (universal serial bus) device, or other suitable removable and / or fixed storage device. Content may be stored in the storage system 130 and loaded from the storage system 130 into the memory 120 where it may be processed by the controller 105. In some embodiments, some of the components shown in FIG. 1 may be omitted. For example, the memory 120 may be a non-volatile memory having the storage capacity of the storage system 130. Accordingly, although shown as a separate component, storage system 130 may be embedded in or included in memory 120.The input devices 135 may be or include any suitable input devices, components, or systems, e.g., physical sensors such as accelerometers, tachometers, thermometers, microphones, analog-to-digital converters, etc., a removable keyboard or keypad, a mouse, and the like. The output devices 140 may include one or more (possibly removable) displays or monitors, motors, servomotors, speakers, and / or any other suitable output devices. Any suitable input / output (I / O) devices may be connected to computing device 100, as shown by blocks 135 and 140. For example, a wired or wireless network interface card (NIC), a universal serial bus (USB) device, a JTAG interface, or an external hard disk may be included in the input devices 135 and / or output devices 140. It will be appreciated that any suitable number of the input devices 135 and output devices 140 may be operatively connected to the computing device 100, as shown by blocks 135 and 140. For example, the input devices 135 and the output devices 140 may be used by a technician or engineer to connect to the computing device 100, update software, and the like. Input and / or output devices or components 135 and 140 may be adapted to communicate with or interface with control or other entities in a vehicle. For example, input and / or output devices or components 135 and 140 may include ports that enable computing device 100 to communicate with an engine control unit or module, a suspension control unit or module, a traction control unit or module, and the like.Embodiments may include an article of manufacture such as a non-transitory readable medium of a computer or processor or a non-transitory storage medium of a computer or processor such as a memory, a floppy disk drive, or a USB flash memory that encodes, contains, or stores instructions (e.g., computer-executable instructions that, when executed by a processor or controller, perform methods disclosed herein), a storage medium such as memory 120, computer-executable instructions such as executable code 125, and a controller such as controller 105.The storage medium may include, but is not limited to, any type of disk including magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs) such as dynamic RAM (DRAM), erasable programmable read-only memories (EPROMs), flash memories, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, or any type of medium suitable for storing electronic instructions including programmable memory devices.Embodiments of the disclosure may include components such as, but are not limited to, a plurality of central processing units (CPUs), or any other suitable general purpose or special purpose processors or controllers (e.g., controllers similar to controller 105), a plurality of input units, a plurality of output units, a plurality of memory units, and a plurality of mass storage units, etc. A system may additionally include other suitable hardware components and / or software components. In some embodiments, a system may include or be, for example, a personal computer, a desktop computer, a portable computer, a laptop computer, a notebook computer, a terminal, a workstation, a server computer, a personal digital assistant (PDA) device, a tablet computer, a network device, or any other suitable computing device.In some embodiments, for example, a system may include or be a plurality of components including a corresponding plurality of central processing units, e.g., a plurality of CPUs as described, a plurality of CPUs embedded in an onboard or vehicle system or network, a plurality of chips, FPGAs or SOCs, microprocessors, transceivers, microcontrollers, a plurality of computer or network devices, any other suitable computing device, and / or any combination thereof. For example, a system as described herein may include one or more devices, such as computing device 100.FIG. 2 illustrates an embodiment of a system 200 and a vehicle 204 that may implement an IDS 208 in accordance with the present disclosure. Portions of the IDS 208 are implemented within the vehicle 204, while other portions of the IDS 208 are implemented on one or more remote servers (which may be implemented within a cloud computing system and may be referred to as cloud backend). In some examples, the cloud computing system may be implemented as a vehicle security operations center (VSOC) 212 that includes portions of the IDS 208. The system 200 according to the present disclosure further includes a fuzzing system or agent 216 configured to continuously perform a fuzzing operation on a system under test 220, as described in more detail below (e.g., in response to a test controller 224). The fuzzing system, the system under test 220, and the test controller 224 may be considered components of the IDS 208 of the present disclosure.In some example implementations, a device (not shown) may communicate with the IDS 208 and other vehicle systems and record CAN messages via a diagnostic port 228 (OBD-II port) of the vehicle 204. Security and vehicle control related CAN messages may be sent to the VSOC 212 and stored in a database (e.g., a VSOC database 232). For example, the device communicates with one or more ECUs 236 of the vehicle 204 via a CAN bus 240. The stored CAN messages are available for visualization and further processing and may be accessible to external services, such as tests performed by the test controller 224, fuzzing system 216, etc. Although described with respect to CAN and CAN messages, the principles of the present disclosure may be implemented in accordance with other types of vehicle networks (e.g., a local interconnect network (LIN)) or bus standards (e.g., FlexRay), Ethernet networks, systems using direct communication links (e.g., using a vehicle connectivity unit), etc.The VSOC 212 is configured to communicate with the vehicle 204, the test controller 224 (e.g., a server or computing device implementing the test controller 224), etc. In some examples, the VSOC 212 is configured to use (e.g., have or communicate with) domain services 244 to store centralized information. For example, the domain services 244 may store directory information to facilitate communication between users / entities, domains, etc. The domain services 244 may include information associated with the VSOC 212, a security incident and event management system (SIEM), the IDS 208, etc.The VSOC 212 may include or communicate with a data management system 246 and a device management system 248. The data management system 246 may store information associated with data collection (e.g., storing data received from the vehicle 204, the test controller 224, other components of the IDS 208, etc.) as well as processing the stored data. The device management system 248 may be configured to implement software updates for digital twins. A digital twin may be a virtual model designed to accurately reflect a physical object. The object under examination, for example a vehicle or an external plug-in device for the diagnostic connection of the vehicle, can be equipped with various sensors which relate to important functional areas. These sensors may generate data about various aspects of the performance of the vehicle, such as energy output, temperature, weather conditions, etc. This data can then be passed to a processing system and applied to the digital copy. Once equipped with such data, the virtual model can be used to execute simulations, examine performance problems, and generate possible improvements, all with the aim of gaining valuable insight - which can then be re-applied to the original physical object. Various software updates may be associated with the digital twin.In some examples, the VSOC 212 includes at least one storage location (e.g., the VSOC database 232, the data management system 246, etc.) that stores, for each vehicle (i.e., for each unique vehicle identifier associated with a respective vehicle), information identifying all hardware platforms of the monitored vehicle 204, a software version of the software program executing on the vehicle 204, a version date of the software program (e.g., a software creation and / or change date), etc. In some examples, this information corresponds to the information provided in a software part list document (or SBOM).The IDS 208 according to the present disclosure implements fuzz (e.g., using the fuzzing system 216), as described in more detail below. For example, the IDS 208 may be implemented as a rule-based IDS configured to execute a main IDS program including a set of rules stored on one or more devices executing the IDS 208 (e.g., an automobile gateway connected to / executed by the VSOC 212, components of the vehicle 204, etc.). The rules may be stored on an integrity protected medium to detect malicious unauthorized changes to the rules.The system under test 220 is configured to store and execute a software program provided in the vehicle 204 (and other vehicles in a fleet of vehicles that the vehicle 204) includes. In other words, the system under test 220 operates in accordance with the same software program (e.g., an emulated version of the software program, a software program executing on a test version of a hardware platform corresponding to the vehicle 204, etc.) provided in the vehicle 204.The fuzzing system 216 continuously tests (performs fuzzing) the software program executed by the system under test 200. For example, fuzzing system 216 provides specially designed inputs (or stimuli) to the software program. These stimuli are designed to excite a particular path of the software program that causes a weak point when executed. Accordingly, the stimuli facilitate the identification of a safety-compromised code portion of the software program as it is executed by the system under test 220. More specifically, the fuzzing system 216 according to the present disclosure provides stimuli suitable for detecting as yet unidentified vulnerabilities.For example, previously identified vulnerabilities may be stored in a central location accessible by the vehicle 204, such as a vulnerabilities database 252 of the VSOC 212. The fuzzing system 216 fuzzes over the system under test 220 to identify vulnerabilities that have not yet been recognized and stored in the vulnerabilities database 252. In other words, fuzzing system 216 continuously (i.e., iteratively) provides different stimuli to attempt to cause different errors associated with execution of the software program on system under test 220. When a fault or vulnerabilities occur, the test controller 224 transmits (in response to the fuzzing system 216) information regarding the identified vulnerabilities to the VSOC 212 to store the information in the vulnerabilities database 252 (e.g., as vulnerabilities entry). The information may include, but is not limited to, a particular version of the software program tested by the system under test 220, a version of the hardware platform emulated by the system under test 220, which includes particular inputs (i.e., stimuli) that have passed to the security vulnerary (i.e., that have caused the security vulnerary to occur), a hash of any values that may function as a unique identifier for the security vulnerary entry, etc. The security vulnerabilities entry may further include previous execution cycles performed by the system under test 220 or fuzzing system 216 prior to detecting the security vulnerabilities, a stack dump, or any additional information that would help a tool (or security analyst) determine an accurate state of the system under test 220 at the time of the security vulnerabilities occurrence (and / or immediately prior to the security vulnerabilities occurrence).The information included in the vulnerary entry may be referred to as a vulnerary information vector (V_fuzz_vuln_id), represented as V_fuzz_vuln_id = {SW_version, HW_version, time_found, data_found, exploit, exploit_fix, hash_ID} where SW_version corresponds to the software version of the software program executed by the system under test 220, HW_version corresponds to the hardware version emulated by the system under test 220, time_found, and data_found correspond to a time and date, respectively, at which the vulnerary was detected, identifies exploit stimuli associated with the vulnerabilities and / or outputs / system behaviors caused by the vulnerary, Thus, the Exploit_fix corresponds to one or more actions / changes performed to correct the vulnerabilities (e.g., a software patch), and the hash_ID corresponds to a hash of one or more values included in the vulnerabilities information vector.Although described as a component of the VSOC 212, the vulnerabilities database 252 may be stored in the same or different location as any of the components of the VSOC 212, the test controller 224 (i.e., a device including the test controller 224, the fuzzing system 216, and the system under test 220), a location external to the VSOC 212, etc. When the fuzzing system 216 detects a new (i.e., previously unidentified) vulnerabilities, the test controller 224 (or other computing device associated with the operation of the system under test 220 and the fuzzing system 216) transmits the vulnerabilities entry (V_fuzz_vuln_id) to the vulnerabilities database 252 via a secure communication channel 256, such as a wireless communication channel. For example, the wireless communication channel may correspond to an encrypted communication channel.The VSOC 212 searches the VSOC database 232 ("queries") to determine whether a software version of the vulnerabilities entry corresponds to a software version deployed on one of the vehicles monitored by the VSOC 212, including the vehicle 204. If no vehicles use the corresponding software version, no corrective operations can be taken. In some examples, the VSOC 212 may simply generate and store a log entry that indicates details of the vulnerary entry and the query.When the VSOC 212 detects a match between the software version of the vulnerary entry and the software version deployed on at least one vehicle monitored by the VSOC 212, the time and date of the vulnerary entry (i.e., the software version implemented by / on the system under test 220) is compared to the time and date of the deployed software version. If the time and date of the vulnerary entry is older than (i.e., earlier in time than) the time and date of the software version provided, the VSOC 212 may ignore the vulnerary entry. For example, the time and date of the vulnerabilities entry that are temporally preceding the time and date of the provided software version may indicate that the provided software version has already been changed / updated to remedy or otherwise treat the vulnerabilities.Conversely, the VSOC 212 and / or other components of the IDS 208 are configured to perform one or more additional processing steps (e.g., correction operations) to remedy the vulnerabilities if the time and date of the vulnerabilities are more recent than the time and date of the provided version (i.e., do not precede in time). The vulnerable code portion corresponding to the detected weak spot may be changed. In some examples, the vulnerable code portion may be changed automatically (e.g., by the test controller 224 and / or other components of the VSOC 212, IDS 208, etc.) and / or by a developer or other user. Once the vulnerable code portion is resolved, the software version can be updated and re-provided in the affected vehicles. The fuzzing system 216 continues to perform fuzzing across the system under test 220, and the fuzzing process is iteratively repeated / performed. In this manner, because the IDS 208 according to the present disclosure is configured to implement fuzz continuously and iteratively, new vulnerabilities can be efficiently identified and corrected.In some examples, the VSOC 212 or other component may determine that the weak spot is not a potential weak spot, but merely corresponds to unexpected (but not abnormal or potentially usable) behavior. Accordingly, rather than repair the corresponding code portion, relevant portions of the IDS 208 may be updated to prevent similar stimuli from causing behavior. For example, for a rule-based IDS, rules corresponding to the identified vulnerabilities may be changed to recognize the stimuli that caused the vulnerabilities as valid inputs.In some examples, the VSOC 212 may be configured to perform all or part of the fuzzing operation to identify vulnerabilities (e.g., in addition to or in place of the fuzzing system 216). For example, a developer or other user may communicate fuzz inputs / stimuli to the VSOC 212, and / or an artificial intelligence or other algorithm (e.g., executed by the data management system 246, the device management system 248, etc.) may provide the fuzz inputs / stimuli. The VSOC 212 may provide the fuzz inputs for different software and hardware versions to different systems under test and / or to deployed vehicles and IDS clients in a fleet. All detected vulnerabilities may be returned to the VSOC 212 to store them in the vulnerabilities database 252, as described above.In some examples, one or more components of the IDS 208 may detect a new (i.e., unrecognized) attack during actual operation of the vehicle 204. In these examples, the IDS 208 may identify the steps taken to perform the attack and provide information about these steps to the fuzzing system 216. The fuzzing system 216 may be configured to provide corresponding inputs to the system under test 200 to duplicate the attack, identify which systems / components of the vehicle 204 are vulnerable to the attack, update the vulnerabilities database 252, and, in some examples, take one or more corrective operations as described herein.FIG. 3 illustrates an example method 300 for identifying a weak spot in an IDS of a vehicle, in accordance with the present disclosure. For example, the method 300 is implemented by one or more computing devices, such as the computing device 100, and components thereof, such as a controller, a processor executing instructions stored in the memory, etc. In embodiments, components implementing one or more steps of the methods 300 may be included in one or more computing devices, such as the vehicle 204, the VSOC 212, the fuzzing system 216, the test controller 224, etc.At 304, the method 300 (e.g., the fuzzing system 216) performs a fuzzing operation on a software program executing on the system under test 220. The fuzzing operation includes providing inputs to the software program (e.g., stimuli) that are configured to mimic invalid or semi-valid, unexpected, or random data that may cause software or system crashes, erroneous outputs, memory leaks, or other errors. At 308, the method 300 (e.g., the fuzz system 216, the system under test 220, the test controller 224, etc.) identifies a vulnerabilities corresponding to one or more fuzz inputs. As an example, the fuzzing system 216 provides the inputs and the test controller 224 monitors outputs, conditions, etc. of the system under test 220. For example, the test controller 224 monitors the system under test 220 to detect outputs or other errors that indicate that the fuzz inputs have caused a weak spot to occur.At 312, the method 300 (e.g., the test controller) generates a vulnerary entry corresponding to the identified vulnerary and transmits the vulnerary entry to the vulnerary database 252. In some examples, the vulnerabilities entry (e.g., the vulnerabilities information vector) may be validated by a validation process before being stored in the database. For example, the validation process may be performed by a developer or other user, artificial intelligence, or other algorithm (e.g., performed by the test controller 224, the VSOC 212, etc., and / or combinations thereof). The validation process may be performed on different information paths in the VSOC 212, the system under test 220, etc.At 316, the method 300 (e.g., the VSOC 212) determines whether a software version of the vulnerabilities entry corresponds to a software version provided on vehicles monitored by the VSOC 212. If so, the method 300 continues to 320. If false, the method 300 continues to 304 to continue the fuzzing operation.At 320, the method 300 (e.g., the VSOC 212) determines whether a time and date of the vulnerary entry are prior to a time and date of the provided software version. If so, the method 300 ignores the vulnerary entry and continues to 304 to continue the fuzzing operation. If false, the method 300 continues to 324.At 324, the method 300 (e.g., the VSOC 212 and / or other components of the IDS 208) performs one or more additional processing steps or actions (e.g., correction operations) to remedy the vulnerabilities. In some examples, the vulnerable code portion may be changed automatically (e.g., by the test controller 224 and / or other components of the VSOC 212, IDS 208, etc.) and / or by a developer or other user. At 328, the method 300 (e.g., the VSOC 212) updates the software version and re-provides it to affected vehicles (i.e., uploads it). The method 300 then continues with 304, and the fuzzing system 216 continues to perform the fuzzing operation.FIG. 4 shows an example method 400 for performing one or more correction operations in response to identifying a weak spot in an IDS of a vehicle, in accordance with the present disclosure. One or more of the correction operations may be performed or omitted, and the correction operations may be performed sequentially (in a same or different order as shown in FIG. 4 ), simultaneously, conditionally, etc. In other words, one or more of the steps of method 400 may be optional.At 404, method 400 detects a vulnerary in response to fuzz inputs provided from fuzz system 216 as described above. As described in this example, detecting the vulnerabilities may include steps associated with detecting the vulnerabilities, creating a vulnerabilities entry, determining whether the software version of the vulnerabilities entry corresponds to a provided software version, etc. At 408, the method 400 (e.g., the test controller 224, the VSOC 212, and / or other components of the IDS 208) determines whether the corresponding software version of the tested software program is actually vulnerable to attacks due to the detected weak point. For example, the weak link may simply correspond to a minor error or correctable performance problem that is not a weak link for an attack. If so, method 400 continues to 412. If false, the method 400 ends (e.g., returns to 304 of the method 300 to continue fuzz).At 412, the method 400 generates an alarm (e.g., an audible or visual indication, a text message, a warning, or an engine light, etc.) and instructions to a user or driver to remedy the vulnerabilities. As an example, the driver may be instructed to put the vehicle in a particular state (e.g., park, turn off, etc.) to automatically apply the correction from the VSOC 212. In other examples, the driver may be instructed to take the vehicle to a dealer or other repair shop to apply the correction.At 416, method 400 (e.g., VSOC 212, in conjunction with one or more of fuzzing systems 216 associated with different vehicles, systems under test, software versions, etc.) provides the stimuli of the vulnerabilities entry to other vehicle components, software versions, hardware versions, etc., to determine whether the same stimuli cause vulnerabilities in other systems. In other words, stimuli that cause a weak spot can be tested in systems in which similar inputs can cause a similar weak spot.At 420, the method 400 (e.g., the fuzzing system 216) implements fingerprinting techniques to create a fingerprint of the identified vulnerary or exploit. In one example, the fuzzing system 216 generates a power consumption fingerprint associated with the occurrence of the weak spot. Accordingly, the weak spot entry may also have a weak spot fingerprint. In some examples, a machine learning or deep neural network model may be applied to the execution of the software program on the system under test 220 while providing the fuzzing inputs. The VSOC 212 determines whether the vulnerabilities are relevant to one of the monitored vehicles, as described above, and if so, provides the vulnerabilities fingerprint to the IDS of the corresponding vehicle (e.g., the IDS 208 of the vehicle 204). The IDS 208 may perform all the correction operations described above, but may also update all the operation rules to include recognition of the weak spot fingerprint. Subsequently, if an intrusion attempt is associated with the detected vulnerabilities and is represented by the corresponding vulnerabilities entry, the IDS 208 may detect the intrusion attempt by matching monitored features of the executed code portion with the vulnerabilities fingerprint. Although described above with respect to power consumption, fingerprinting techniques may also be based on other operating features, such as hardware counters typically available in processors and microcontrollers.At 424, the method 400 (e.g., the VSOC 212) updates models (e.g., machine learning or deep neural network models) of the IDS 208 to include the weak point fingerprint. For example, the IDS 208 may be a signature-based or anomaly-based IDS.FIGS. 5-11 show example systems and devices that may implement IDSs and IDS methods according to the present disclosure. FIG. 5 shows a schematic diagram of interaction between a computer controlled machine 500 and a control system 502 (including, but not limited to, an industrial control system in a manufacturing facility). The computer controlled machine 500 includes an actuator 504 and a sensor 506. The actuator 504 may include one or more actuators, and the sensor 506 may include one or more sensors. The sensor 506 is configured to sense a state of the computer controlled machine 500. The sensor 506 may be configured to encode the sensed state into sensor signals 508 and transmit sensor signals 508 to the control system 502. Non-limiting examples of the sensor 506 include video, radar, LiDAR, audio (e.g., a microphone), ultrasonic, and motion sensors. In some embodiments, sensor 506 is an optical sensor configured to capture optical images of an environment proximate to computer-controlled machine 500.The control system 502 is configured to receive sensor signals 508 from the computer controlled machine 500. As set forth below, the control system 502 may be further configured to calculate actuator control commands 510 in dependence on the sensor signals and transmit actuator control commands 510 to the actuator 504 of the computer controlled machine 500.As shown in FIG. 5, the control system 502 includes a receiving unit 512. The receiving unit 512 may be configured to receive sensor signals 508 from the sensor 506 and convert sensor signals 508 into input signals x. In an alternative embodiment, sensor signals 508 are received directly as input signals x, without receiving unit 512. Each input signal x may be a portion of each sensor signal 508. The receiving unit 512 may be configured to process each sensor signal 508 to generate each input signal x. The input signal x may include data corresponding to an image recorded by the sensor 506.The control system 502 includes a classifier 514. Classifier 514 may be configured to classify input signals x into one or more labels using a machine learning (ML) algorithm, such as a neural network. The classifier 514 is configured to be parameterized by parameters such as those described above (e.g., the parameter θ). The parameter θ may be stored in and provided by the nonvolatile memory 516. The classifier 514 is configured to determine output signals y from input signals x. Each output signal y comprises information that assigns one or more labels to each input signal x. The classifier 514 may transmit output signals y to the conversion unit 518. The conversion unit 518 is configured to convert output signals y into actuator control commands 510. The control system 502 is configured to transmit actuator control commands 510 to the actuator 504, which is configured to actuate the computer controlled machine 500 in response to actuator control commands 510. In some embodiments, actuator 504 is configured to actuate the computer controlled machine 500 directly based on output signals y.Upon receipt of actuator control commands 510 by the actuator 504, the actuator 504 is configured to perform an action corresponding to the associated actuator control command 510. The actuator 504 may include control logic configured to convert actuator control commands 510 to a second actuator control command used to control the actuator 504. In one or more embodiments, actuator control commands 510 may be used to control a display in place of or in addition to an actuator.In some embodiments, the control system 502 includes a sensor 506 instead of or in addition to the computer controlled machine 500 including the sensor 506. The control system 502 may also include an actuator 504 in place of or in addition to the computer controlled machine 500 including the actuator 504.As shown in FIG. 5, the control system 502 also includes a processor 520 and a memory 522. The processor 520 may include one or more processors. The memory 522 may include one or more storage devices. The classifier 514 (e.g., ML algorithms) of one or more embodiments may be implemented by the control system 502 including a non-volatile memory 516, a processor 520, and a memory 522.The non-volatile memory 516 may include one or more persistent storage devices, such as a hard disk, optical drive, tape drive, non-volatile solid state device, cloud storage, or any other device capable of permanently storing information. Processor 520 may include one or more devices selected from high performance computer systems (HPC), including high performance cores, microprocessors, microcontrollers, digital signal processors, microcomputers, central processing units, field programmable gate arrays, programmable logic devices, state machines, logic circuits, analog circuits, digital circuits, or any other devices that manipulate signals (analog or digital) based on computer-executable instructions in memory 522. The memory 522 may include a single memory device or a number of memory devices including, but not limited to, random access memory (RAM), volatile memory, non-volatile memory, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, cache memory, or any other device capable of storing information.The processor 520 may be configured to read into and execute computer-executable instructions stored in the non-volatile memory 516 and embodying one or more IDS methods of one or more embodiments. The non-volatile memory 516 may include one or more operating systems and applications. The non-volatile memory 516 may store compiled and / or interpreted computer programs created using a variety of programming languages and / or technologies, including, without limitation, and either alone or in combination, Java, C, C++, C#, Objective C, Fortran, Pascal, Java Script, Python, Perl, and PL / SQL.When executed by processor 520, the computer-executable instructions of non-volatile memory 516 may cause control system 502 to implement one or more of the IDS methods described herein. The non-volatile memory 516 may also include data that supports the functions, features, and processes of the one or more embodiments described herein.The program code embodying the algorithms and / or methods described herein may be distributed individually or jointly as a program product in a variety of different forms. The program code may be distributed using a computer readable storage medium having computer readable program instructions thereon for causing a processor to execute aspects of one or more embodiments. Computer readable storage media that are inherently non-transitory may include volatile and non-transitory, as well as removable and non-removable tangible media implemented in any method or technology for storing information, such as computer readable instructions, data structures, program modules, or other data. Computer readable storage media may further include RAM, ROM, Erasable Programmable Read Only Memory (EPROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other solid state memory technology, a portable compact disc read-only memory (CD-ROM) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be read by a computer. Computer readable program instructions may be downloaded from a computer readable storage medium to a computer, other type of programmable data processing device, or other device, or via a network to an external computer or storage device.Computer readable program instructions stored on a computer readable medium may be used to direct a computer, other types of programmable data processing devices, or other devices to function in a particular manner, such that the instructions stored on the computer readable medium produce an article of manufacture including instructions that implement the functions, acts, and / or operations indicated in the flowcharts or diagrams. In certain alternative embodiments, the functions, acts, and / or operations indicated in the flowcharts and diagrams may be rearranged, serially processed, and / or simultaneously processed, which is consistent with one or more embodiments. Moreover, all flowcharts and / or diagrams may include more or fewer nodes or blocks than those corresponding to one or more embodiments.The processes, methods, or algorithms can be embodied in whole or in part using suitable hardware components, such as application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), state machines, controllers or other hardware components or devices, or a combination of hardware, software, and firmware components.FIG. 6 shows a schematic diagram of the control system 502 configured to control the vehicle 600, which may be an at least partially autonomous vehicle or robot. The vehicle 600 includes an actuator 504 and a sensor 506. The sensor 506 may include one or more video sensors, cameras, radar sensors, microphones, ultrasonic sensors, LiDAR sensors, and / or position sensors (e.g., GPS). One or more of the one or more specific sensors may be integrated with the vehicle 600. Alternatively or in addition to one or more of the specific sensors mentioned above, the sensor 506 may include a software module configured to determine a state of the actuator 504 when executed. A non-limiting example of a software module includes a weather information software module configured to determine a current or future state of the weather in the vicinity of the vehicle 600 or elsewhere.The classifier 514 of the control system 502 of the vehicle 600 may be configured to detect objects in the vicinity of the vehicle 600 depending on input signals x. In such an embodiment, the output signal y may include information characterizing the proximity of objects to the vehicle 600. An actuator control command 510 may be determined in accordance with this information. The actuator control command 510 may be used to avoid collisions with the detected objects.In some embodiments, the vehicle 600 is an at least partially autonomous vehicle, wherein the actuator 504 may be embodied in a brake, a propulsion system, an engine, a powertrain, or a steering of the vehicle 600. Actuator control commands 510 may be determined to control actuator 504 such that vehicle 600 avoids collisions with detected objects. Detected objects may also be classified according to what classifier 514 keeps most likely, such as pedestrians or trees. The actuator control commands 510 may be determined depending on the classification. In a scenario where an hostile attack may occur, the system described above may be further trained to better detect objects or identify a change in lighting conditions or angle for a sensor or camera on the vehicle 600.In some embodiments where the vehicle 600 is an at least partially autonomous robot, the vehicle 600 may be a mobile robot configured to perform one or more functions, such as flying, swimming, diving, and walking. The mobile robot may be an at least partially autonomous lawn mower or an at least partially autonomous cleaning robot. In such embodiments, the actuator control command 510 may be determined such that a drive unit, steering unit, and / or braking unit of the mobile robot may be controlled such that the mobile robot may avoid collisions with identified objects.In some embodiments, the vehicle 600 is an at least partially autonomous robot in the form of a garden robot. In such an embodiment, the vehicle 600 may use an optical sensor and / or a microphone as the sensor 506 to determine a condition of plants in an environment proximate the vehicle 600. The actuator 504 may be a nozzle configured to spray chemicals. Depending on an identified species and / or condition of the plants, the actuator control command 510 may be determined to cause the actuator 504 to spray the plants with an appropriate amount of suitable chemicals.The vehicle 600 may be an at least partially autonomous robot in the form of a household appliance. Non-limiting examples of household appliances include a washing machine, oven, microwave oven, or dishwasher. In such a vehicle 600, the sensor 506 may be an optical sensor or a microphone configured to detect a state of an object to be processed by the household appliance. If the household appliance is a washing machine, for example, the sensor 506 can detect a state of the laundry in the washing machine. The actuator control command 510 may be determined based on the detected condition of the laundry.FIG. 7 shows a schematic diagram of the control system 502 configured to control the system 700 (e.g., a manufacturing machine), such as a punch cutter, a milling cutter, or a downhole drill, of the manufacturing system 702, which is part of a production line, for example. The control system 502 may be configured to control the actuator 504, which is configured to control the system 700 (e.g., the manufacturing machine).The sensor 506 of the system 700 (e.g., the manufacturing machine) may be an optical sensor or a microphone configured to sense one or more characteristics of the manufactured product 704. The classifier 514 may be configured to determine a state of the manufactured product 704 from one or more of the detected characteristics. The actuator 504 may be configured to control the system 700 (e.g., the manufacturing machine) depending on the particular condition of the manufactured product 704 for a subsequent manufacturing step of the manufactured product 704. The actuator 504 may be configured to control functions of the system 700 (e.g., the manufacturing machine) on a subsequently manufactured product 706 of the system 700 (e.g., the manufacturing machine) depending on the particular state of the manufactured product 704.FIG. 8 shows a schematic diagram of the control system 502 configured to control a power tool 800, such as a drilling machine or a driver, having an at least partially autonomous mode. The control system 502 may be configured to control the actuator 504, which in turn is configured to control the power tool 800.The sensor 506 of the power tool 800 may be an optical sensor or microphone configured to sense one or more characteristics of the work surface 802 and / or the fastener 804 driven into the work surface 802. The classifier 514 may be configured to determine a state of the work surface 802 and / or the fastener 804 relative to the work surface 802 from one or more of the detected characteristics. The condition may be that the fastener 804 is flush with the working surface 802. The condition may alternatively be the hardness of the working surface 802. The actuator 504 may be configured to control the power tool 800 to adjust the driving function of the power tool 800 depending on the particular state of the fastener 804 relative to the work surface 802, or one or more sensed characteristics of the work surface 802. For example, the actuator 504 may interrupt the drive function when the state of the fastener 804 is flush relative to the working surface 802. As another non-limiting example, the actuator 504 may apply additional or less torque depending on the hardness of the working surface 802.FIG. 9 shows a schematic diagram of the control system 502 configured to control the automated personal assistant 900. The control system 502 may be configured to control the actuator 504, which is configured to control the automated personal assistant 900. The automated personal assistant 900 may be configured to control a household appliance such as a washing machine, oven, oven, microwave, or dishwasher.The sensor 506 may be an optical sensor and / or an audio sensor. The optical sensor may be configured to receive video images of gestures 904 of the user 902. The audio sensor may be configured to receive a voice command of the user 902.The control system 502 of the automated personal assistant 900 may be configured to determine actuator control commands 510 configured to control the control system 502. The control system 502 may be configured to determine actuator control commands 510 in accordance with sensor signals 508 of the sensor 506. The automated personal assistant 900 is configured to transmit sensor signals 508 to the control system 502. The classifier 514 of the control system 502 may be configured to execute a gesture recognition algorithm to identify the gesture 904 being performed by the user 902, determine actuator control commands 510, and transmit the actuator control commands 510 to the actuator 504. Classifier 514 may be configured to retrieve information from non-volatile memory in response to gesture 904 and output the retrieved information in a form suitable for receipt by user 902.FIG. 10 shows a schematic diagram of the control system 502 configured to control the monitoring system 1000. The monitoring system 1000 may be configured to physically control access through the door 1002. Sensor 506 may be configured to detect a scene relevant to the decision whether access is granted. The sensor 506 may be a microphone or an optical sensor configured to generate and transmit image and / or video data. Such data may be used by the control system 502 to detect a person's face.The classifier 514 of the control system 502 of the monitoring system 1000 may be configured to interpret the image and / or video data by matching identities of known persons stored in the non-volatile memory 516 and thereby determining the identity of a person. Classifier 514 may be configured to generate an actuator control command 510 in response to the interpretation of the image and / or video data. The control system 502 is configured to transmit the actuator control command 510 to the actuator 504. In this embodiment, the actuator 504 may be configured to lock or unlock the door 1002 in response to the actuator control command 510. In some embodiments, non-physical, logical access control is also possible.The monitoring system 1000 may also be an observation system. In such an embodiment, the sensor 506 may be a microphone or an optical sensor configured to detect a monitored scene and the control system 502 is configured to control a display 1004. Classifier 514 is configured to determine a classification of a scene, e.g., whether the scene detected by sensor 506 is suspect. The control system 502 is configured to transmit an actuator control command 510 to the display 1004 in response to the classification. The display 1004 may be configured to adjust the displayed content in response to the actuator control command 510. For example, the display 1004 may emphasize an object that is classified as suspect by the classifier 514. Using an embodiment of the disclosed system, the monitoring system may predict that objects will appear at certain times in the future.FIG. 11 shows a schematic diagram of the control system 502 configured to control the imaging system 1100, for example, an MRI apparatus, an X-ray imaging apparatus, or an ultrasound apparatus. The sensor 506 may be an image sensor, for example. The classifier 514 may be configured to determine a classification of all or a portion of the captured image. The classifier 514 may be configured to determine or select an actuator control command 510 in response to the classification obtained from the trained neural network. For example, classifier 514 may interpret a region of a captured image as potentially anomalous. In this case, the actuator control command 510 may be determined or selected to cause the display 1102 to display the imaging and emphasize the potentially abnormal area.Although exemplary embodiments have been described above, it is not intended that these embodiments describe all possible forms encompassed by the claims. The words used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the disclosure. As described above, the features of various embodiments may be combined to form other embodiments of the disclosure that may not be explicitly described or illustrated. While various embodiments could be described as being advantageous or preferred over other embodiments or implementations of the prior art with respect to one or more desired characteristics, those skilled in the art recognize that one or more functions or characteristics can be compromised to achieve desired overall system attributes, which depend on the specific application and implementation. These attributes may include, but are not limited to, cost, strength, durability, life cycle cost, marketability, appearance, packaging, size, serviceability, weight, mullability, assemblyability, etc. Insofar as embodiments are described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics, these embodiments are not outside the scope of the disclosure and may be desirable for particular applications.

Claims

A method of operating an attack detection system (IDS) for a device, the method comprising: performing a fuzzing operation on a software program executed on a system to be tested, wherein the software program corresponds to a provided software program on the device monitored by the IDS, and the system to be tested is configured to emulate at least one system of the device, the fuzzing operation comprising (i) supplying fuzzing inputs to the software program, (ii) monitoring outputs of the software program during execution on the system to be tested, and (iii) detecting, based on the outputs, a weak point for attacks in the software program caused by the supplying of the fuzzing inputs to the software program; generating and storing a vulnerabilities entry corresponding to the detected vulnerabilities, the vulnerabilities entry including information for identifying the detected vulnerabilities; and updating, based on the vulnerabilities entry, at least one of (i) a component of the IDS and (ii) a code portion of the provided software program.The method of claim 1, wherein supplying the fuzz inputs comprises supplying fuzz inputs configured to cause errors in at least one of a plurality of code portions of the software program.The method of claim 1, wherein generating and storing the vulnerabilities entry comprises storing the vulnerabilities in a vulnerabilities database.The method of claim 1, wherein the vulnerary entry comprises at least one of a software version of the software program, a hardware version emulated by the system under test executing the software program, a time and date the vulnerary was detected, the supplied fuzzing inputs, an identification of a remedy for the detected vulnerary, and a hash of one or more values included in the vulnerary entry.The method of claim 1, further comprising determining whether the detected vulnerabilities correspond to a vulnerabilities for the provided software program monitored by the IDS by at least one of (i) determining whether a software version of the software program corresponds to a software version of the provided software program, and (ii) determining whether the software version of the software program temporally precedes the software version of the provided software program.The method of claim 1, wherein the updating comprises at least one of: performing at least one correction operation on the software program and updating the provided software program on the device based on the at least one correction operation; and modifying a configuration of the software program.The method of claim 1, further comprising (i) comparing the vulnerabilities entry to previously detected vulnerabilities and (ii) storing the vulnerabilities entry in a vulnerabilities database in response to a determination that the vulnerabilities entry does not correspond to any of the previously detected vulnerabilities.The method of claim 1, further comprising at least one of (i) generating an alarm in response to detecting the weak spot, and (ii) generating instructions to a user of the device in response to detecting the weak spot.The method of claim 1, further comprising, in response to detecting the vulnerabilities, (i) generating a fingerprint associated with an operating characteristic of the system under test during the detection of the vulnerabilities, and (ii) updating the IDS based on the fingerprint.The method of claim 1, further comprising: detecting, by the IDS, an attack on the device; supplying fuzz inputs to the software program based on the detected attack on the device; updating at least one of (i) the component of the IDS and (ii) the code portion of the provided software program based on the performance of the software program in response to the fuzz inputs.An attack detection system (IDS), the IDS comprising: a fuzzing system configured to perform a fuzzing operation on a software program executed on a system under test, the software program corresponding to a provided software program on a device monitored by the IDS, and the system under test configured to emulate at least one system of the device, the fuzzing system configured to perform the fuzzing operation configured to (i) provide fuzzing inputs to the software program and (ii) monitor outputs of the software program as it is executed on the system under test; a test controller configured to (i) identify, based on the outputs, a vulnerabilities for attacks in the software program caused by the supplying of the fuzzing inputs to the software program, and (ii) generate and transmit a vulnerabilities entry corresponding to the identified vulnerabilities to a vulnerabilities database, wherein the vulnerabilities entry includes information identifying the identified vulnerabilities.The IDS of claim 11, further comprising the vulnerabilities database.The IDS of claim 11, further comprising a security operation center configured to update at least one of (i) a component of the IDS and (ii) a code portion of the provided software program based on the vulnerabilities entry.The IDS of claim 11, wherein the fuzzing system to supply the fuzzing inputs supplies fuzzing inputs configured to cause errors in at least one of a plurality of code portions of the software program.The IDS of claim 11, wherein the vulnerabilities entry comprises at least one of a software version of the software program, a hardware version emulated by the system under test executing the software program, a time and date at which the vulnerabilities were detected, the supplied fuzz inputs, an identification of a revision for the detected vulnerabilities, and a hash of one or more values included in the vulnerabilities entry.The IDS of claim 11, further comprising the system under test.The IDS of claim 11, wherein at least one / more of the test controller and a component of a security operations center is configured to determine whether the detected weak point corresponds to a weak point for attacks for the provided software program monitored by the IDS by at least one of (i) determining whether a software version of the software program corresponds to a software version of the provided software program, and (ii) determining whether the software version of the software program precedes the software version of the provided software program in time.The IDS of claim 17, wherein at least one / more of the test controller and the component of the VSOC is configured to (i) perform at least one correction operation on the software program, (ii) in response to detecting the weak spot, generate a fingerprint associated with an operating characteristic of the system under test during detection of the weak spot, (iii) update the IDS based on the fingerprint, and (iv) update the provided software program on the device based on the at least one correction operation.The IDS of claim 11, further comprising a security operations center configured to at least one of: compare the vulnerary entry to previously detected vulnerabilities and store the vulnerary entry in the vulnerary database in response to a determination that the vulnerary entry does not correspond to any of the previously detected vulnerabilities; and generate an alarm in response to the detection of the vulnerary and generate instructions for a user of the device in response to the detection of the vulnerary.A computing device configured to implement at least a portion of an attack detection system (IDS), the computing device comprising a processing device configured to execute instructions stored in memory to cause the IDS to: perform a fuzzing operation on a software program executed on a system under test, wherein the software program corresponds to a provided software program on a vehicle device monitored by the IDS, and the system under test is configured to emulate at least one system of the device, the fuzzing operation comprising: (i) providing fuzzing inputs to the software program, (ii) monitoring outputs of the software program during execution on the system under test, and (iii) detecting, based on the outputs, a vulnerabilities caused by supplying the fuzzing inputs to the software program for attacks in the software program; generating a vulnerabilities entry corresponding to the detected vulnerabilities, the vulnerabilities entry including information identifying the detected vulnerabilities; determining whether the vulnerabilities entry matches previously detected vulnerabilities associated with the software program; storing the vulnerabilities entry in a vulnerabilities database in response to a determination that the vulnerabilities entry does not correspond to any of the previously detected vulnerabilities; and updating, based on the vulnerabilities entry, at least one of (i) a component of the IDS and (ii) a code portion of the provided software program.

Images