WO2022254519A1 - 監視装置、監視システムおよび監視方法 - Google Patents

監視装置、監視システムおよび監視方法 Download PDF

Info

Publication number
WO2022254519A1
WO2022254519A1 PCT/JP2021/020677 JP2021020677W WO2022254519A1 WO 2022254519 A1 WO2022254519 A1 WO 2022254519A1 JP 2021020677 W JP2021020677 W JP 2021020677W WO 2022254519 A1 WO2022254519 A1 WO 2022254519A1
Authority
WO
WIPO (PCT)
Prior art keywords
monitoring
unit
software
virtual machine
execution authority
Prior art date
Application number
PCT/JP2021/020677
Other languages
English (en)
French (fr)
Inventor
亮 平野
良浩 氏家
剛 岸川
智之 芳賀
潤 安齋
吉治 今本
Original Assignee
パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to PCT/JP2021/020677 priority Critical patent/WO2022254519A1/ja
Priority to JP2022567193A priority patent/JP7189397B1/ja
Priority to EP22815997.6A priority patent/EP4350548A1/en
Priority to PCT/JP2022/021731 priority patent/WO2022255247A1/ja
Priority to CN202280036869.4A priority patent/CN117355832A/zh
Priority to JP2022176683A priority patent/JP7253663B2/ja
Publication of WO2022254519A1 publication Critical patent/WO2022254519A1/ja
Priority to US18/519,690 priority patent/US20240086290A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/301—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is a virtual computing platform, e.g. logically partitioned systems
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W50/00—Details of control systems for road vehicle drive control not related to the control of a particular sub-unit, e.g. process diagnostic or vehicle driver interfaces
    • B60W50/04—Monitoring the functioning of the control system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures

Definitions

  • the present disclosure relates to a monitoring device and a monitoring method.
  • Patent Document 1 a monitoring virtual machine and a monitoring target virtual machine are arranged on virtualization software, and the monitoring target is monitored from the monitoring virtual machine, thereby detecting an abnormality in the monitoring target. A method for detecting is described.
  • IVI In-Vehicle Ifortainment
  • ADAS Advanced If the Driver Assistance System is integrated into one ECU, tampering with the memory area associated with the ADAS control method by a third party's malicious application is a serious problem that threatens passenger safety.
  • Patent Literature 1 can detect an abnormality in the monitoring target if the monitoring virtual machine has not been tampered with, but if the monitoring virtual machine itself has been tampered with by a third party's malicious application. In such a case, there is a problem that anomalies cannot be detected.
  • the present disclosure solves the conventional problem by monitoring a second security countermeasure mechanism implemented in a low-trust area from a first security countermeasure mechanism implemented in a trustworthy area, By monitoring the monitoring target from the monitoring program, it is possible to increase the reliability of the monitoring result of the second security countermeasure mechanism. That is, even if the second security countermeasure mechanism with low reliability is tampered with, the tampering can be detected from the first security countermeasure mechanism, so an abnormality occurring in the ECU can be detected.
  • a monitoring device includes two or more monitoring units that monitor at least one of software and a communication log as a monitoring target, and each of the monitoring units has one of two types of execution authority.
  • a first monitoring module operating with a first execution privilege so as to build a monitoring trust chain in which software of a low-trust monitoring module is monitored from at least one high-trust monitoring module.
  • the monitoring unit of is a monitoring device including the software of the second monitoring unit that operates with the second execution authority as a monitoring target.
  • a monitoring method includes two or more monitoring steps for monitoring at least one of software and a communication log as a monitoring target, wherein each of the monitoring steps has one of two types of execution authority
  • a first monitoring run under a first execution right such that software running under one execution right and performing a low-trust monitoring step can be monitored by at least one high-trust monitoring step.
  • a step is a monitoring method in which a monitoring target includes software that executes a second monitoring step that is executed with a second execution authority.
  • the monitoring device of the present disclosure even if a monitoring program installed in a low-reliability area has been tampered with, an abnormality that has occurred in the ECU can be detected.
  • FIG. 1 is a diagram showing an overall configuration diagram of a monitoring system according to an embodiment of the present disclosure.
  • FIG. 2 is a diagram showing a configuration diagram of an in-vehicle system according to an embodiment of the present disclosure.
  • FIG. 3 is a diagram showing a configuration diagram of an integrated ECU according to the embodiment of the present disclosure.
  • FIG. 4 is a diagram showing details of a configuration diagram of an integrated ECU according to the embodiment of the present disclosure.
  • FIG. 5 is a diagram showing a configuration diagram of an external application according to the embodiment of the present disclosure.
  • FIG. 6 is a diagram showing a configuration diagram of a control application according to the embodiment of the present disclosure.
  • FIG. 7 is a diagram showing a configuration diagram of a video application according to the embodiment of the present disclosure.
  • FIG. 1 is a diagram showing an overall configuration diagram of a monitoring system according to an embodiment of the present disclosure.
  • FIG. 2 is a diagram showing a configuration diagram of an in-vehicle system according to an embodiment
  • FIG. 8 is a diagram showing a configuration diagram of an external virtual machine according to the embodiment of the present disclosure.
  • FIG. 9 is a diagram showing a configuration diagram of a control virtual machine according to the embodiment of the present disclosure.
  • FIG. 10 is a diagram showing a configuration diagram of a video virtual machine according to the embodiment of the present disclosure.
  • FIG. 11 is a diagram showing a configuration diagram of a hypervisor according to an embodiment of the present disclosure.
  • FIG. 12 is a diagram showing a configuration diagram of a secure application according to the embodiment of the present disclosure.
  • FIG. 13 is a diagram showing a configuration diagram of a monitoring server according to an embodiment of the present disclosure;
  • FIG. 14 is a diagram showing an example of monitoring information according to the embodiment of the present disclosure.
  • FIG. 15 is a diagram showing an example of monitoring information according to the embodiment of the present disclosure.
  • FIG. 16 is a diagram illustrating an example of system states according to the embodiment of the present disclosure.
  • FIG. 17 is a diagram illustrating an example of a monitoring configuration according to an embodiment of the present disclosure;
  • FIG. 18 is a diagram illustrating an example of a monitoring configuration according to an embodiment of the present disclosure;
  • FIG. 19 is a diagram illustrating an example of a monitoring configuration according to an embodiment of the present disclosure;
  • FIG. 20 is a diagram illustrating an example of a monitoring configuration according to an embodiment of the present disclosure;
  • FIG. 21 is a diagram illustrating an example of monitoring change rules according to the embodiment of the present disclosure.
  • FIG. 22 is a diagram illustrating an example of a monitoring result display according to the embodiment of the present disclosure
  • FIG. 23 is a diagram illustrating an example of a monitoring result display according to the embodiment of the present disclosure
  • FIG. 24 is a diagram illustrating a sequence of monitoring processing by an application monitoring unit in the embodiment of the present disclosure
  • 25 is a diagram illustrating a sequence of monitoring processing by a VM monitoring unit in the embodiment of the present disclosure
  • FIG. FIG. 26 is a diagram illustrating a sequence of monitoring processing by the HV monitoring unit in the embodiment of the present disclosure
  • FIG. 27 is a diagram illustrating a sequence of monitoring processing by an SA monitoring unit in the embodiment of the present disclosure
  • FIG. 28 is a diagram showing a sequence of monitoring server notification processing in the embodiment of the present disclosure.
  • FIG. 24 is a diagram illustrating an example of a monitoring result display according to the embodiment of the present disclosure
  • FIG. 24 is a diagram illustrating a sequence of monitoring processing by an application monitoring unit in the embodiment of the present disclosure
  • FIG. 29 is a diagram illustrating a sequence of processing for changing monitoring from the management unit in the embodiment of the present disclosure
  • FIG. 30 is a diagram showing a flowchart of monitoring processing in the embodiment of the present disclosure.
  • FIG. 31 is a diagram showing a flowchart of monitoring change processing in the embodiment of the present disclosure.
  • FIG. 32 is a diagram showing Modification 1 of the details of the configuration diagram of the integrated ECU in the embodiment of the present disclosure.
  • FIG. 33 is a diagram showing a second modified example of the details of the configuration diagram of the integrated ECU in the embodiment of the present disclosure.
  • a monitoring device includes two or more monitoring units that monitor at least one of software and a communication log as a monitoring target, and the monitoring units each include two types of , so that a monitoring trust chain can be constructed in which software of a low-reliability monitoring unit is monitored from at least one high-reliability monitoring unit.
  • a first monitoring unit that operates with execution authority is a monitoring device that includes software of a second monitoring unit that operates with second execution authority as a monitoring target.
  • the active monitoring unit has the advantage of being able to employ sophisticated and complex algorithms.
  • the monitoring device includes three or more monitoring units, each of the monitoring units operates with execution authority of one of three types of execution authority, and software of the monitoring unit with low reliability is at least
  • the first monitoring unit that operates with the first execution authority installs the software of the monitoring unit that operates with the second execution authority.
  • a monitoring device including, as a monitoring target, software of a third monitoring section in which at least one of the first monitoring section and the second monitoring section operates with a third execution authority. .
  • the active monitoring unit has the advantage of being able to employ sophisticated and complex algorithms.
  • the monitoring device includes four or more monitoring units, each of the monitoring units operates with one of four types of execution authority, and at least one piece of software of a low-reliability monitoring unit is used.
  • the first monitoring unit operating with the first execution authority monitors the software of the monitoring unit operating with the second execution authority. including as a target, at least one of the first monitoring unit and the second monitoring unit including software of a third monitoring unit that operates with a third execution authority, as a monitoring target, and the first monitoring at least one of the monitoring unit, the second monitoring unit, and the third monitoring unit includes, as a monitoring target, software of the fourth monitoring unit that operates with a fourth execution authority.
  • the active monitoring unit has the advantage of being able to employ sophisticated and complex algorithms.
  • the monitoring device operates on a secure application, a virtual software platform, and two or more virtual machines
  • the first execution authority includes the execution authority of the secure application, the execution authority of the virtual software infrastructure, and the kernel of the virtual machine.
  • execution authority wherein the second execution authority is one of virtual software infrastructure execution authority, virtual machine kernel execution authority, and virtual machine user authority;
  • the authority is one of a virtual machine kernel execution authority and a virtual machine user authority, and the fourth execution authority is a virtual machine user authority.
  • communication logs such as software in the user space of the virtual machine, network logs in the user space of the virtual machine, and system calls between the user space and the kernel space of the virtual machine Since it can be assumed that acquisition is difficult, separating the monitoring units for each execution authority has the effect of enabling monitoring of a wider range of monitoring targets.
  • software that operates with secure app execution privileges, hypervisor execution privileges, and virtual machine kernel privileges is implemented with a simple algorithm that does not include vulnerabilities, monitoring that operates with strong execution privileges A simple algorithm can be adopted for the part, and an advanced and complicated algorithm can be adopted for the monitoring part which operates with weak execution authority.
  • the monitoring device operates on a virtual software platform and two or more virtual machines, and when there are two or more monitoring units that operate with the execution authority assigned to the virtual machines, the first virtual machine
  • the monitoring unit includes the software of the monitoring unit of the second virtual machine as a monitoring target, and the first virtual machine and the second virtual machine are classified according to the possibility of being tampered with by an attacker. It is a monitoring device.
  • virtual machines with vehicle control functions are isolated from the external network, and it can be assumed that secure design and implementation have been fully considered to meet the requirements of a high functional safety level. can be treated as a reliable first virtual machine.
  • the monitoring unit of the second monitoring machine which has a high tampering risk, must be monitored from the execution authority of the secure application or hypervisor. Since the monitoring unit of the second monitoring machine can be monitored from the second monitoring unit, there is an effect of simplifying the software that operates with the execution authority of the secure application and the execution authority of the hypervisor.
  • the monitoring device operates on a secure application, a host operating system, one or more virtual software platforms and one or more virtual machines, or one or more container virtualization platforms and two or more containers
  • the first execution authority, the second execution authority, the third execution authority, and the fourth execution authority are a secure application execution authority, a host operating system execution authority, and a virtual software infrastructure.
  • the monitoring unit of the first virtual machine includes the software of the monitoring unit of the second virtual machine as a monitoring target, and the first virtual machine and the second virtual machine are tampered with by an attacker.
  • the monitoring unit of the first container includes the software of the monitoring unit of the second container in its monitoring targets.
  • the first container and the second container are monitoring devices classified according to the possibility of being tampered with by an attacker.
  • the host operating system uses a hypervisor, which is a virtualization software platform, to run and manage multiple virtual machines.
  • a hypervisor which is a virtualization software platform, to run and manage multiple virtual machines.
  • the reliability of the virtual machine or container will differ depending on the possibility of tampering, such as the presence or absence of a connection function with an external network, so multiple monitoring units are monitored.
  • By building a trust chain of even if the monitoring part of the second virtual machine or second container with low trust is hijacked, the monitoring part of the first virtual machine with high trust or the monitoring part of the second container There is an effect that an abnormality can be detected from the monitoring unit of one container.
  • the monitoring unit responds to an event including at least one of elapse of a predetermined time, elapse of a predetermined external network connection time, system startup, system restart, establishment of external network connection, and external device connection. and monitors the monitoring target.
  • the monitoring unit whose integrity is verified by the front-stage monitoring unit is not a serial monitoring method that verifies the rear-stage monitoring unit.
  • the load of the monitoring process can be flexibly distributed without imposing a load on the system, such as performing the monitoring process using the idle time of the CPU of each virtual machine.
  • the monitoring device operates on an in-vehicle system, and the monitoring unit monitors the elapse of a predetermined running time, the elapse of a predetermined stop time, the elapse of a predetermined running distance, the switching of the running mode, and the refueling or power supply.
  • the monitoring unit performs the monitoring according to at least one of the number of executions of the monitoring process of the other monitoring unit, the number of times the monitoring process is determined to be abnormal, and the number of times the monitoring process is determined to be normal. Observe the target.
  • the first monitoring unit monitors the software of the second monitoring unit.
  • the second monitoring unit to be monitored by the first monitoring unit detects an abnormality once
  • the first monitoring unit executes the software monitoring process of the second monitoring unit.
  • the monitoring process can be executed only when an abnormality occurs in the monitoring target of the second monitoring unit, and the number of monitoring processes can be reduced.
  • the first monitoring unit executes the software monitoring process of the second monitoring unit once.
  • the monitoring processing of the first monitoring unit can be reduced, and the number of times of monitoring processing can be reduced. This has the effect of reducing the overhead by reducing the number of times the execution mode is switched, since it is assumed that the execution mode needs to be switched in order to operate the software with strong execution authority.
  • the monitoring unit acquires at least one of a hash value, a mask value, and a copy value of the monitoring target software stored in a memory or storage as an acquired value.
  • the monitoring device compares a predefined expected value with an acquired value, determines normality when they match, and determines abnormality when they do not match.
  • the software is tampered with, the expected value and the obtained value will differ, so it has the effect of being able to determine whether the software has been tampered with.
  • a hash value it is possible to determine falsification more efficiently than a duplicate value, and by using a mask value, it is possible to determine the presence or absence of falsification more efficiently than a duplicate value.
  • the duplicate value it is possible to determine falsification more accurately than the hash value, and by using the mask value, it is possible to determine falsification more accurately than the hash value.
  • the software includes at least one of a virtual software platform program and configuration file, a virtual machine kernel program and configuration file, a user application program and configuration file on the virtual machine, and the monitoring unit program and configuration file.
  • a monitoring device is a monitoring device.
  • the monitoring unit acquires the communication log, verifies the communication log using at least one of a permission list, a rejection list, and normal statistical information, If it is included in the allow list, it is determined to be normal; if it is not included, it is determined to be abnormal; if it is not included in the deny list, it is determined to be normal; if it is included, it is determined to be normal; It is a monitoring device that determines normality when there is no deviation from the statistical information, and determines normality when it deviates.
  • the communication log includes Ethernet (registered trademark), CAN (registered trademark) protocol, FlexRay (registered trademark) protocol, SOME/IP protocol, SOME/IP-SD protocol, system call, and hyper call.
  • Ethernet registered trademark
  • CAN registered trademark
  • FlexRay registered trademark
  • SOME/IP SOME/IP-SD protocol
  • system call system call
  • hyper call hyper call
  • the network protocol installed in the in-vehicle system it is possible to determine communication abnormalities using protocol-specific parameters. Furthermore, the sender and destination can be acquired from the communication log determined to be abnormal, and there is an effect that the monitoring unit and the monitoring target in which the abnormality may occur can be specified. Furthermore, by monitoring system calls and hypercalls, which are privileged instructions, it is possible to determine anomalies that occur at the boundaries of execution rights, and to identify a monitoring unit and a monitoring target that may cause anomalies.
  • the monitoring unit is a monitoring device that changes at least one of the monitoring frequency, monitoring accuracy, and monitoring means of the monitoring target according to the priority set for each monitoring target.
  • the priority includes execution authority of the monitoring target, whether or not the virtual machine on which the monitoring unit or the monitoring operates has an external network connection function, and whether or not the virtual machine on which the monitoring unit or the monitoring operates is a vehicle.
  • a monitoring device that is set according to at least one of whether or not it has a control function.
  • the monitoring device further monitors a combination of the priority included in the monitoring information and the monitoring person and the monitoring target included in the monitoring target, according to the state or event of the system in which the monitoring device operates.
  • a monitoring device including a manager for changing at least one of the configurations.
  • the monitoring information As a result, if the importance of monitoring targets differs depending on the system state or event, it can be assumed that it is difficult to set the monitoring information as an appropriate fixed value.
  • By flexibly changing the monitoring configuration effective monitoring is possible. For example, by flexibly changing the priority and changing the monitoring frequency, monitoring accuracy, and monitoring method according to the priority, it is possible to focus on monitoring targets with a high risk of falsification within a limited resource. effective.
  • by changing the monitoring information so that when one of the monitoring modules becomes inoperable, such as when one of the virtual machines is restarted, the monitoring of the other monitoring modules that cannot operate can be taken over. It has the effect of continuously monitoring the target.
  • another monitoring unit takes over the monitoring of the monitoring target, so that there is an effect that the monitoring target can be monitored from a reliable monitoring unit.
  • another monitoring unit additionally performs monitoring of the monitoring target, so that there is an effect that monitoring can be strengthened by a plurality of monitoring units.
  • another monitoring unit takes over the monitoring of the monitoring target, thereby reducing the system impact due to resource pressure.
  • the management unit determines whether or not an external network connection is being established, the occurrence of an external network connection establishment event, the system state of the monitoring machine, the monitoring result of the monitoring unit, the execution authority of the monitoring unit that has detected an abnormality,
  • the monitoring device changes the priority according to at least one of the execution authority of the software that detected the abnormality and the destination or source of the communication log that detected the abnormality.
  • the state of network connections affects the possibility of attack, so it has the effect of changing the priority according to changes in the attack possibility of the monitored target.
  • a software error it is assumed that there is a high possibility that an attack will occur in the same virtual machine software as the error software, software that operates with the same execution privileges, or software in the monitoring unit that has determined the error. Therefore, there is an effect that the priority can be changed according to the change of attack possibility.
  • a communication abnormality is determined, there is a high possibility that an abnormality has occurred at the transmission source of the communication, and there is a high possibility that an attack will develop on the transmission destination of the communication. There is an effect that can change the degree.
  • the monitoring device operates on an in-vehicle system
  • the management unit changes the priority of a monitoring target operated by a virtual machine having a vehicle control function according to the running state of the vehicle.
  • the state is a monitoring device that is either stopped, in manual operation, in advanced driver assistance, or in automatic operation.
  • control commands related to running, turning, and stopping of the vehicle are sent from the control virtual machine software, which controls the engine, steering, braking, etc. Since it can be assumed that the control ECU follows the control command and the influence of software falsification is large, there is an effect that the software of the control virtual machine having the vehicle control function can be monitored intensively by raising the priority thereof. On the other hand, when the vehicle is stopped or manually driven, it can be assumed that the control ECU does not follow control commands, and the influence of software tampering is small. By lowering the degree, there is an effect that priority can be given to monitoring processing of other monitoring targets.
  • the management unit configures the monitoring configuration so that, even after the monitoring configuration is changed, a monitoring trust chain can be constructed in which software of a low-reliability monitoring unit is monitored from at least one high-reliability monitoring unit. It is a monitoring device that changes the
  • the management unit determines whether or not an external network connection is being established, the occurrence of an external network connection establishment event, the system state of the virtual machine, the monitoring result of the monitoring unit, the execution authority of the monitoring unit that has detected an abnormality, A monitoring device that changes a monitoring configuration according to at least one of the execution authority of software that has detected an abnormality and the destination or source of a communication log that has detected an abnormality.
  • the status of network connections affects the possibility of attacks, so it has the effect of changing the monitoring configuration according to changes in the attack potential of the monitored target.
  • another monitoring unit takes over the monitoring of the monitored object, which has the effect of enabling continuous monitoring of the monitored object. be.
  • another monitoring unit takes over the monitoring of the monitoring target, so that there is an effect that the monitoring target can be monitored from a reliable monitoring unit.
  • another monitoring unit additionally performs monitoring of the monitoring target, so that there is an effect that monitoring can be strengthened by a plurality of monitoring units.
  • the CPU or memory resources of one virtual machine are under pressure, another monitoring unit takes over the monitoring of the monitored object, thereby reducing the system impact due to resource pressure.
  • the monitoring device operates on an in-vehicle system
  • the management unit changes a monitoring configuration related to a virtual machine having a vehicle control function according to the running state of the vehicle, and the running state of the vehicle is:
  • a monitoring device that is either stopped, in manual operation, in advanced driving assistance, or in automatic operation.
  • control commands related to running, turning, and stopping of the vehicle are sent from the control virtual machine software, which controls the engine, steering, braking, etc. Since it can be assumed that the control ECU follows the control command and the influence of software tampering is large, there is an effect that the monitoring configuration can be changed so that the software of the control virtual machine is monitored by a plurality of monitoring units. When the vehicle is stopped or manually driven, it can be assumed that the control ECU does not follow the control command, and the influence of software tampering is small. be.
  • the management unit includes means for selecting one of two or more monitoring configurations defined in advance, and a directed graph having the monitoring unit as the top, the person in charge of monitoring as the starting point of the road, and the monitoring target as the end point of the road.
  • the management unit stores the monitoring configuration as a tree structure in which the monitoring unit is a node, the person in charge of monitoring is a parent node, and the monitoring target is a child node, and reconstructs the tree structure using a predetermined algorithm, A monitoring device for changing the monitoring configuration.
  • At least one of the monitoring units will select the monitoring target when some of the monitoring units are disabled or an abnormality is detected in some of the monitoring units. This has the effect of making it possible to recalculate the monitoring configuration so that it can be monitored.
  • the monitoring device is a monitoring device further comprising a monitoring server notification unit that notifies the monitoring server of the monitoring result.
  • a monitoring system comprising a monitoring device and a monitoring server, wherein the monitoring device includes two or more monitoring units for monitoring software or a communication log as monitoring targets, a monitoring unit identifier, a monitoring target identifier, a normal a monitoring server communication unit that transmits at least two of a judgment time and an abnormality judgment time to the monitoring server as monitoring results, and the monitoring server receives the monitoring results and displays them on a graphical user interface It is a monitoring system provided with the monitoring result display part which displays the said monitoring result.
  • the monitoring result display unit displays the monitoring results in association with the system architecture, means for emphasizing the monitoring unit that has detected an abnormality or the monitoring target in which the abnormality has been detected, and the monitoring results in association with a predetermined timeline. and displaying the monitoring results on a graphical user interface by at least one means of emphasizing the normality determination time or the abnormality determination time.
  • the security analyst can intuitively grasp the location of the monitoring department, the location of the monitored object, and the monitoring results. be.
  • security analysts can intuitively grasp the time series of monitoring results, and in the event of an anomaly, there is an effect that they can more quickly consider countermeasures such as updating software.
  • the monitoring server further changes at least one of the monitoring target, a monitoring unit that monitors the monitoring target, the priority of the monitoring target, and a monitoring method corresponding to the priority.
  • a monitoring system comprising: a monitoring information changing unit that accepts and requests the change to the monitoring device; and the monitoring device has a monitoring information updating unit that updates the monitoring information in response to a request from the monitoring information changing unit.
  • a first monitoring step executed with a first execution right is executed with a second execution right such that software executing a low-trust monitoring step can be monitored with at least one high-trust monitoring step.
  • the monitoring method includes software for executing the second monitoring step to be monitored.
  • the active monitoring unit has the advantage of being able to employ sophisticated and complex algorithms.
  • FIG. 1 is an overall configuration diagram of a monitoring system according to Embodiment 1 of the present disclosure.
  • the monitoring system consists of a monitoring server 10 and an in-vehicle system 20, and the monitoring server 10 and the in-vehicle system 20 are connected via an external network 30.
  • the external network 30 is, for example, the Internet.
  • the communication method of the external network 30 may be wired or wireless.
  • the wireless communication system may be Wi-Fi (registered trademark), which is an existing technology, 3G/LTE (Long Term Evolution), Bluetooth, or V2X communication system.
  • the monitoring server 10 is a device that acquires monitoring results, which are information about the security status of the in-vehicle system 20, from the in-vehicle system 20 and displays the monitoring results using a graphical user interface.
  • the monitoring server 10 is used, for example, at a security operation center when a security analyst checks the monitoring results and considers countermeasures such as software update when an abnormality occurs in the in-vehicle system 20 .
  • the in-vehicle system 20 is a device that performs communication control, vehicle control, video output, etc., monitors the security status of the in-vehicle system 20, and notifies the monitoring server 10 of the security status monitoring results. Although only one in-vehicle system 20 is shown in FIG. 1 , each of the one or more in-vehicle systems 20 transmits the security status monitoring result to the monitoring server 10 . Details of the in-vehicle system 20 will be described later.
  • FIG. 2 is a diagram showing a configuration diagram of an in-vehicle system according to an embodiment of the present disclosure.
  • the in-vehicle system 20 includes an integrated ECU 200, a gateway ECU 300, a steering ECU 400a, a brake ECU 400b, a zone ECU 500, a front camera ECU 600a, and a rear camera ECU 600b.
  • CAN 40 which is a kind of network protocol CAN (Control Area Network).
  • network protocols used in in-vehicle systems such as CAN-FD and FlexRay protocol may be used instead of CAN.
  • gateway ECU 300 the steering ECU 400a, and the brake ECU 400b are connected via the CAN 41.
  • Ethernet 50 is a protocol of Ethernet (registered trademark), which is a kind of network protocol.
  • the Ethernet 50 for example, is a SOME/IP (Scalable Service-Oriented Middleware over IP) protocol.
  • SOME/IP Scalable Service-Oriented Middleware over IP
  • SOME/IP-SD Scalable Service-Oriented Middleware over IP
  • CAN-XL CAN-XL
  • other network protocols used in in-vehicle systems may be used.
  • ZoneECU 500, the front camera ECU 600a, and the rear camera ECU 600b are connected via the Ethernet 50.
  • ZoneECU 500 the front camera ECU 600a, and the rear camera ECU 600b are connected via Ethernet 51.
  • the integrated ECU 200 and the monitoring server 10 are connected via an external network 30 .
  • the integrated ECU 200 performs communication control for transmitting and receiving messages via the external network 30, the CAN 40, and the Ethernet 50, vehicle control for instructing the gateway ECU 300 and the ZoneECU 500 to control the vehicle via the CAN 40 and the Ethernet 50, and an infotainment system and an instrument. It is an ECU that outputs video to the management panel, monitors the security state of the integrated ECU 200, and notifies the monitoring server 10 of the monitoring results. Details of the integrated ECU 200 will be described later.
  • the gateway ECU 300 is an ECU that mediates messages exchanged between the integrated ECU 200, the steering ECU 400a, and the brake ECU 400b.
  • the steering ECU 400a is an ECU that controls the steering of the steering wheel mounted on the vehicle.
  • the brake ECU 400b is an ECU that controls the brakes mounted on the vehicle.
  • ECUs that control the engine and body of the vehicle are used to control the running, turning, and stopping of the vehicle.
  • the ZoneECU 500 is an ECU that mediates messages exchanged between the integrated ECU 200 and the front camera ECU 600a and the rear camera ECU 600b.
  • the front camera ECU 600a is an ECU that acquires images from a camera mounted in front of the vehicle.
  • the rear camera ECU 600b is an ECU that acquires images from a camera mounted behind the vehicle.
  • FIG. 3 is a configuration diagram of integrated ECU 200 according to the first embodiment of the present disclosure.
  • the integrated ECU 200 includes an external application A100, a control application A200, a video application A300 (hereinafter, the external application A100, the control application A200, and the video application A300 may be collectively referred to as applications), and an external virtual machine VM100.
  • a control virtual machine VM200, a video virtual machine VM300 (hereinafter, the external virtual machine VM100, the control virtual machine VM200, and the video virtual machine VM300 may be collectively referred to as virtual machines), a hypervisor HV100, It has a secure application SA100 and a secure operating system SOS100.
  • the hypervisor HV100 is a virtual software platform such as a hypervisor, and is software that executes and manages one or more virtual machines.
  • hypervisors are distinguished between a bare-metal type hypervisor called type 1 and a host type called type 2.
  • type 1 is generally used in consideration of processing overhead by the hypervisor.
  • Type 1 hypervisors are less likely to contain vulnerabilities due to their smaller code size, and can be assumed to be more reliable than applications and virtual machines.
  • a type 1 hypervisor will be described as an example, but a virtualization system using a type 2 hypervisor or a container-type virtualization application may also be used.
  • the secure operating system SOS100 is a reliable operating system implemented without vulnerabilities. Furthermore, since the operating system software is verified from the Root Of Trust of reliable hardware when the system is started, it can be assumed to be the most reliable among applications, virtual machines, and hypervisor HV100.
  • a secure operating system is realized, for example, by controlling an execution environment called TEE (Trusted Execution Environment). Also, for example, in the Cortex-A family of ARM-based CPUs (Central Processing Units), it can be realized by the TrustZone mechanism, which is one of the standard functions. It can also be realized by Apple's SEP (Secure Enclave Processor) or Google's TitanM.
  • the secure application SA100 is a reliable application that is implemented without vulnerabilities. Since it runs on the reliable secure operating system SOS100, it can be assumed to be more reliable than the application, virtual machine, and hypervisor HV100. On the other hand, the program of secure application SA100 is required to be simple, since implementation without vulnerability is required.
  • the external application A100 is an application that communicates with the monitoring server 10 via the external network 30. Since it is connected to the external network 30 that can be an intrusion point for attackers, it can be assumed that it is more vulnerable than the control application A200 and the video application A300 that are not connected to the external network 30 .
  • the external virtual machine VM100 is an operating system that runs the external application A100. Since the external application A100, which can be an intrusion point for attackers, is running, it can be assumed to be more vulnerable than the control virtual machine VM200 and the video virtual machine VM300.
  • the control application A200 is an application that communicates with the gateway ECU 300 via the CAN 40 and controls the vehicle. Since it is not connected to the external network 30, it can be assumed to be more reliable than the external application A100. Furthermore, software development related to vehicle control is designed and implemented in a secure manner in order to comply with functional safety standards, so it can be assumed to be more reliable than the external application A100. However, if the control application A200 is hijacked, the vehicle control function can be used by an attacker, so it can be assumed that the safety is greatly affected.
  • the control virtual machine VM200 is an operating system that runs the control application A200. Since it is not connected to the external network 30, it can be assumed that the possibility of becoming an intrusion point for an attacker is low. Furthermore, software development related to vehicle control is designed and implemented in a secure manner in order to comply with functional safety standards. However, if the control virtual machine VM200 is hijacked, the vehicle control function can be used by an attacker, so it can be assumed that the impact will be greater than if the external virtual machine VM100 or the video virtual machine VM300 were hijacked.
  • the video application A300 is an application that communicates with ZoneECU 500 via Ethernet 50, acquires camera video, etc., and outputs video to the infotainment system, instrument panel, and head-up display. Camera images are also used as information to realize advanced driving support functions such as autonomous driving. Since it is not connected to the external network 30, it is less likely to become an intrusion point for attackers, and can be assumed to be more reliable than the external application A100. Also, if the video application A300 is hijacked, the vehicle control function cannot be used by an attacker, so it can be assumed that the impact on safety is small compared to the case where the control virtual machine VM200 is hijacked.
  • the video virtual machine VM300 is an operating system that runs the video application A300. Since it is not connected to the external network 30, it is less likely to become an intrusion point for attackers, and can be assumed to be more reliable than the external application A100. Also, if the video application A300 is hijacked, the vehicle control function cannot be used by an attacker, so it can be assumed that the impact on safety is small compared to the case where the control virtual machine VM200 is hijacked.
  • the CPU can assign multiple privilege levels to each program.
  • ARM-based CPUs support EL (Exception Level), and Intel-based CPUs support Protection Ring.
  • the program can be executed securely by controlling two types of execution environments, the secure world and the normal world, using the TEE.
  • five types of execution authority can be selectively used by controlling this privilege level and two types of execution environments.
  • the secure operating system is assigned the strongest secure execution authority (PL4)
  • the applications on the operating system are assigned the next strongest secure execution authority (PL3)
  • the hypervisor HV 100 Assign the next strongest execution rights (PL2)
  • assign the virtual machine the next strongest execution rights (PL1)
  • the software may be tampered with due to vulnerabilities or design flaws, so software that operates with strong execution authority is required to be a simple program.
  • the external application A100 is most likely to be tampered with, and thus has low reliability.
  • the possibility of falsification decreases in the order of the application SA100 and the secure operating system SOS100.
  • a low possibility of falsification means high reliability.
  • An attacker exploits the vulnerability of the external application A100 to intrude into the external virtual machine VM100 from the external network 30 and gain user authority. Then, by exploiting vulnerabilities such as system calls of the external virtual machine VM100, kernel privileges of the external virtual machine VM100 are acquired. Then, by exploiting the vulnerability of the hypervisor HV100 such as hypercall, the authority of the hypervisor HV100 or the authority of the control virtual machine VM200 or the video virtual machine VM300 is acquired.
  • a hypercall is, for example, a privileged instruction for instructing internal communication between virtual machines and activation and termination of virtual machines.
  • the security countermeasure mechanism includes an application monitoring unit, a virtual machine monitoring unit, a HV monitoring unit HV110, and an SA monitoring unit SA110, which will be described later.
  • the integrated ECU 200 is equipped with a function of monitoring the connection.
  • FIG. 4 is a diagram showing details of a configuration diagram of the integrated ECU according to the first embodiment of the present disclosure.
  • the external application A100 includes an application monitoring unit A110 that monitors external communication and software in the application area.
  • the control application A200 includes an application monitoring unit A210 that monitors CAN communication and software in the application area.
  • An application monitoring unit A310 that monitors software in the area is provided (hereinafter, the application monitoring unit A210, the application monitoring unit A210, and the application monitoring unit A210 may be collectively referred to as an application monitoring unit).
  • the external virtual machine VM100 includes a VM monitoring unit VM110 that monitors system calls, hyper calls, software in the VM area (also called OS area or kernel area), and software in the application area.
  • the hypervisor HV100 also includes an HV monitoring unit HV110 that monitors software in the HV area and software in the VM area.
  • the secure application SA100 also includes an SA monitoring unit SA110 that monitors software in the HV area and software in the VM area, and a management unit SA120 that manages monitoring information (hereinafter referred to as an application monitoring unit, a virtual machine monitoring unit, and an HV monitoring unit).
  • HV110 and SA monitoring unit SA110 may be collectively referred to as a multi-layer monitoring unit). Details of the monitoring information will be described later.
  • the details of the application, the application monitoring unit, the virtual machine, the virtual machine monitoring unit, the hypervisor HV100, the HV monitoring unit HV110, the secure application SA100, and the SA monitoring unit SA110 will be described later.
  • the application, virtual machine, hypervisor HV100, and secure application SA100 each have an application monitoring unit, a virtual machine monitoring unit, and a HV monitoring unit HV110, which are security countermeasure mechanisms.
  • the SA monitor SA110 is introduced.
  • an attacker can disable the security countermeasure mechanism by tampering with the software of the security countermeasure mechanism that is executed with the acquired execution authority, simply introducing the security countermeasure mechanism is insufficient.
  • the SA monitoring unit SA110 monitors the software of the HV monitoring unit HV110
  • the HV monitoring unit HV110 monitors the software of the virtual machine monitoring unit
  • the virtual machine monitoring unit monitors the software of the application monitoring unit. Even if the application monitoring unit has been tampered with, the virtual machine monitoring unit can detect an abnormality, and even if the software of the virtual machine monitoring unit has been tampered with, the HV monitoring unit HV110 can detect an abnormality.
  • the SA monitor SA110 can detect an abnormality. In this way, by monitoring each monitoring unit from at least one multi-layered monitoring unit operating with stronger execution authority or higher reliability, even if one monitoring unit is tampered with and disabled, can also detect anomalies from other monitoring units. Since monitoring is chained from the SA monitoring unit SA110, which is reliable software, to the hypervisor HV100, virtual machines, and applications, it is difficult for an attacker to avoid all monitoring. As described above, in a multi-tiered supervisory chain of trust, build a chain of supervisors from supervisors with stronger execution authority or higher trust to supervisors with weaker execution authority or lower trust. Call it build.
  • FIG. 5 is a diagram showing a configuration diagram of an external application according to Embodiment 1 of the present disclosure.
  • the external application A100 obtains navigation information, obtains streaming information such as music and video, and downloads update software using an external communication unit A101 that communicates via the external network 30, and external communication and system calls. It comprises an external application execution unit A102, an application area storage unit A103 that is a storage and memory for storing external application programs and setting files, and an application monitoring unit A110.
  • the application monitoring unit A110 includes a monitoring target acquiring unit A111, a system state acquiring unit A112, a monitoring unit A113, a monitoring information storage unit A114, a monitoring information updating unit A115, and a monitoring result notification unit A116.
  • the monitoring target acquisition unit A111 has a function of acquiring information related to software to be monitored from the application area storage unit A103 and acquiring information related to external communication logs from the external communication unit A101.
  • the system status acquisition unit A112 has a function of acquiring the Internet connection status from the external communication unit A101 and the security status from the monitoring unit A113 as system status.
  • the monitoring unit A113 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit A111 with the expected value included in the monitoring information stored in the monitoring information storage unit A114, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match. Furthermore, a function to determine whether or not a specific message included in the external communication log is abnormal by using the external communication log acquired by the monitoring target acquiring unit A111, using the permission list or the denial list, and statistical information during normal times. have
  • the monitoring information storage unit A114 has a function of storing monitoring information including information on monitoring personnel, monitoring targets, expected values, and priorities.
  • the monitoring information updating unit A115 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit A116 has a function of notifying the management unit SA120 of monitoring results and system status.
  • the application monitoring unit A110 can monitor software in the application area and external communication, and can acquire the Internet connection status and the security status of the external application A100. Monitoring of external communications is assumed to be a complex algorithm using statistical information.
  • FIG. 6 is a diagram showing a configuration diagram of a control application according to Embodiment 1 of the present disclosure.
  • the control application A200 includes a CAN communication unit A201 that communicates with the gateway ECU 300 via the CAN 40, and a control application execution unit A202 that instructs control such as running, turning, and stopping of the vehicle of the VM 100 using CAN communication and system calls. , an application area storage unit A203, which is a storage and memory for storing programs and setting files of control applications, and an application monitoring unit A210.
  • the application monitoring unit A210 includes a monitoring target acquiring unit A211, a system state acquiring unit A212, a monitoring unit A213, a monitoring information storage unit A214, a monitoring information updating unit A215, and a monitoring result notification unit A216.
  • the monitoring target acquisition unit A211 has a function of acquiring information on software to be monitored from the application area storage unit A203 and acquiring information on CAN communication logs from the CAN communication unit A201.
  • the system state acquisition unit A212 has a function of acquiring the vehicle state such as the driving state, the distance traveled since startup, the elapsed time since startup from the control application execution unit A202, and the security state from the monitoring unit A113 as the system state.
  • the monitoring unit A213 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit A211 with the expected value included in the monitoring information stored in the monitoring information storage unit A214, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match. Furthermore, the CAN communication log acquired by the monitoring target acquisition unit A211 is a function of determining whether or not a specific message contained in the CAN log is abnormal using the permission list or the denial list and normal statistical information.
  • the monitoring information storage unit A214 has a function of storing monitoring information including information on monitoring personnel, monitoring targets, expected values, and priorities.
  • the monitoring information updating unit A215 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit A216 has a function of notifying the management unit SA120 of monitoring results and system status.
  • the application monitoring unit A210 can monitor software in the application area and CAN communication, and can acquire the state of the vehicle and the security state of the control application A200. It is assumed that CAN communication monitoring will be a complex algorithm with statistical information.
  • FIG. 7 is a diagram showing a configuration diagram of a video application according to Embodiment 1 of the present disclosure.
  • the video application A300 includes an Ethernet communication unit A301 that communicates with the ZoneECU 500 via the Ethernet 50, a video application execution unit A302 that acquires camera video using Ethernet communication and system calls and outputs the video to a display, and a video application.
  • the application monitoring unit A310 includes a monitoring target acquisition unit A311, a system state acquisition unit A312, a monitoring unit A313, a monitoring information storage unit A314, a monitoring information updating unit A315, and a monitoring result notification unit A316.
  • the monitoring target acquisition unit A311 has a function of acquiring information on software to be monitored from the application area storage unit A303 and information on Ethernet communication logs from the Ethernet communication unit A301.
  • the system status acquisition unit A312 has a function of acquiring the security status as the system status from the monitoring unit A313.
  • the monitoring unit A313 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit A311 with the expected value included in the monitoring information stored in the monitoring information storage unit A314, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match. Furthermore, the Ethernet communication log acquired by the monitoring target acquiring unit A311 is used to determine whether or not a specific message contained in the Ethernet communication log is abnormal using the permission list or the denial list and normal statistical information. have a function.
  • the monitoring information storage unit A314 has a function of storing monitoring information including information on monitoring personnel, monitoring targets, expected values, and priorities.
  • the monitoring information updating unit A315 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit A316 has a function of notifying the management unit SA120 of monitoring results and system status.
  • the application monitoring unit A310 can monitor software in the application area and Ethernet communication, and can acquire the security status of the video application A300.
  • Ethernet communication monitoring is assumed to be a complex algorithm with statistical information.
  • FIG. 8 is a diagram showing a configuration diagram of an external virtual machine according to Embodiment 1 of the present disclosure.
  • the external virtual machine VM100 stores an application communication unit VM101 that receives a system call from the external application execution unit A102, a system call control unit VM102 that executes the system call, a program of the external virtual machine VM100, middleware, and a setting file. It comprises a VM area storage unit VM103 which is a storage and a memory for processing, a hypercall calling unit VM104 which calls a hypercall, and a VM monitoring unit VM110.
  • the VM monitoring unit VM110 includes a monitoring target acquisition unit VM111, a system state acquisition unit VM112, a monitoring unit VM113, a monitoring information storage unit VM114, a monitoring information update unit VM115, and a monitoring result notification unit VM116.
  • the monitoring target acquisition unit VM111 has a function of acquiring information on software to be monitored from the VM area storage unit VM103 and the application area storage unit A103, and acquiring information on system calls from the application communication unit VM101.
  • the system state acquisition unit VM112 has a function of acquiring the security state from the monitoring unit VM113 as the system state.
  • the monitoring unit VM113 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit VM111 with the expected value included in the monitoring information stored by the monitoring information storage unit VM114, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match. Furthermore, the system call log acquired by the monitoring target acquisition unit VM 111 is used to determine whether or not a specific system call included in the system call log is abnormal using the permission list or the denial list and normal statistical information. have a function.
  • the monitoring information storage unit VM 114 has a function of storing monitoring information including information on monitoring personnel, monitoring targets, expected values, and priorities.
  • the monitoring information update unit VM115 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit VM116 has a function of notifying the management unit SA120 of the monitoring result and system status.
  • the VM monitoring unit VM110 can monitor software and system calls in the application area and VM area, and can acquire the security status of the external virtual machine VM100 and the external application A100.
  • System call monitoring is assumed to be a complex algorithm with statistical information.
  • FIG. 9 is a diagram showing a configuration diagram of a control virtual machine according to Embodiment 1 of the present disclosure.
  • the control virtual machine VM200 stores an application communication unit VM201 that receives a system call from the control application execution unit A202, a system call control unit VM202 that executes the system call, programs of the control virtual machine VM200, middleware, and setting files.
  • a VM area storage unit VM203 which is a storage and a memory for processing data, a hypercall calling unit VM204 for calling a hypercall, and a VM monitoring unit VM210.
  • the VM monitoring unit VM210 includes a monitoring target acquisition unit VM211, a system state acquisition unit VM212, a monitoring unit VM213, a monitoring information storage unit VM214, a monitoring information update unit VM215, and a monitoring result notification unit VM216.
  • the monitoring target acquisition unit VM211 has a function of acquiring information on software to be monitored from the VM area storage unit VM203 and the application area storage unit A103, and acquiring information on system calls from the application communication unit VM201. It has a function of acquiring information about a hypercall from the call control unit HV102.
  • the system state acquisition unit VM212 has a function of acquiring the security state from the monitoring unit VM213 as the system state.
  • the monitoring unit VM213 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit VM211 with the expected value included in the monitoring information stored by the monitoring information storage unit VM214, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match. Further, the system call log acquired by the monitoring target acquisition unit VM211 is used to determine whether or not a specific system call included in the system call log is abnormal using the permission list or the denial list and normal statistical information. have a function. Furthermore, the hypercall log acquired by the monitoring target acquisition unit VM211 is checked by using the permission list or the denial list and the statistical information of the normal time to determine whether or not a specific hypercall included in the hypercall log is abnormal. have a function.
  • the monitoring information storage unit VM 214 has a function of storing monitoring information including information on the person in charge of monitoring, the target of monitoring, the expected value, and the priority.
  • the monitoring information update unit VM215 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit VM216 has a function of notifying the management unit SA120 of the monitoring result and system status.
  • the VM monitoring unit VM210 can monitor software, system calls, and hypercalls in the application area and VM area, and can acquire the security status of the control virtual machine VM200 and the control application A200. Monitoring of system calls and hypercalls is assumed to be a complex algorithm using statistical information.
  • hypercall monitoring is performed by the control virtual machine VM200, it may be performed by the hypervisor HV100.
  • FIG. 10 is a diagram showing a configuration diagram of a video virtual machine according to Embodiment 1 of the present disclosure.
  • the image virtual machine VM300 includes an application communication unit VM301 that receives a system call from the image application execution unit A302, a system call control unit VM302 that executes the system call, a program of the image virtual machine VM300, middleware, and a setting file. It comprises a VM area storage unit VM303 which is storage and memory for storing, a hypercall calling unit VM304 which calls a hypercall, and a VM monitoring unit VM310.
  • the VM monitoring unit VM310 includes a monitoring target acquisition unit VM311, a system state acquisition unit VM312, a monitoring unit VM313, a monitoring information storage unit VM314, a monitoring information update unit VM315, and a monitoring result notification unit VM316.
  • the monitoring target acquisition unit VM311 has a function of acquiring information on software to be monitored from the VM area storage unit VM303 and the application area storage unit A303, and acquiring information on system calls from the application communication unit VM301.
  • the system state acquisition unit VM312 has a function of acquiring the security state from the monitoring unit VM313 as the system state.
  • the monitoring unit VM313 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit VM311 with the expected value included in the monitoring information stored by the monitoring information storage unit VM314, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match. Further, the system call log acquired by the monitoring target acquisition unit VM311 is used to determine whether or not a specific system call included in the system call log is abnormal using the permission list or the denial list and normal statistical information. have a function.
  • the monitoring information storage unit VM 314 has a function of storing monitoring information including information on monitoring personnel, monitoring targets, expected values, and priorities.
  • the monitoring information update unit VM315 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit VM316 has a function of notifying the management unit SA120 of the monitoring result and system status.
  • the VM monitoring unit VM310 can monitor software and system calls in the application area and VM area, and can acquire the security status of the video virtual machine VM300 and the video application A300.
  • System call monitoring is assumed to be a complex algorithm with statistical information.
  • FIG. 11 is a diagram showing a configuration diagram of a hypervisor according to Embodiment 1 of the present disclosure.
  • the hypervisor HV100 stores a virtual machine communication unit HV101 that receives hypercalls from hypercall calling units VM304, VM305, and VM306, a hypercall control unit HV102 that executes hypercalls, a program for the hypervisor HV100, and a setting file.
  • HV area storage unit HV103 and HV monitoring unit HV110 which are storages and memories to be stored.
  • the HV monitoring unit HV110 includes a monitoring target acquiring unit HV111, a system state acquiring unit HV112, a monitoring unit HV113, a monitoring information storage unit HV114, a monitoring information updating unit HV115, and a monitoring result notification unit HV116.
  • the monitoring target acquisition unit HV111 has a function of acquiring information about software to be monitored from the HV area storage unit HV103, the VM area storage unit VM103, the VM area storage unit VM203, and the VM area storage unit VM303.
  • the system state acquisition unit HV112 has a function of acquiring the system state of the virtual machine, the CPU utilization rate, the memory utilization rate, and the security state from the monitoring unit HV113 as the system state.
  • the monitoring unit HV113 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit HV111 with the expected value included in the monitoring information stored in the monitoring information storage unit HV114, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match.
  • the monitoring information storage unit HV114 has a function of storing monitoring information including information on monitoring personnel, monitoring targets, expected values, and priorities.
  • the monitoring information update unit HV115 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit HV116 has a function of notifying the management unit SA120 of monitoring results and system status.
  • the HV monitoring unit HV110 can monitor the external virtual machine VM100, the control virtual machine VM200, the video virtual machine VM300, and the software in the HV area. Can get state and security state.
  • FIG. 12 is a diagram showing a configuration diagram of a secure application according to Embodiment 1 of the present disclosure.
  • the secure application SA100 comprises an SA monitoring part SA110 and a management part SA120.
  • the SA monitoring unit SA110 includes a monitoring target acquiring unit SA111, a system state acquiring unit SA112, a monitoring unit SA113, a monitoring information storage unit SA114, a monitoring information updating unit SA115, and a monitoring result notification unit SA116.
  • the monitoring target acquisition unit SA111 has a function of acquiring information about software to be monitored from the HV area storage unit HV103, the VM area storage unit VM103, the VM area storage unit VM203, and the VM area storage unit VM303.
  • the system state acquisition unit SA112 has a function of acquiring the security state from the monitoring unit SA113 as the system state.
  • the monitoring unit SA113 compares the acquired value of the software-related information acquired by the monitoring target acquisition unit SA111 with the expected value included in the monitoring information stored in the monitoring information storage unit SA114, and if the acquired value and the expected value are different, It has a function to determine that it is abnormal and that it is normal when the obtained value and the expected value match.
  • the monitoring information storage unit SA114 has a function of storing monitoring information including information on monitoring personnel, monitoring targets, expected values, and priorities.
  • the monitoring information updating unit SA115 has a function of updating monitoring information in response to a request from the management unit SA120.
  • the monitoring result notification unit SA116 has a function of notifying the management unit SA120 of the monitoring result and system status.
  • the management unit SA120 includes a monitoring result acquisition unit SA121, a system state acquisition unit SA122, a monitoring configuration storage unit SA123, a monitoring change rule storage unit SA124, a monitoring information change unit SA125, and a monitoring server communication unit SA126.
  • the monitoring result acquisition unit SA121 has a function of receiving monitoring results from the monitoring result notification units A116, A216, A316, VM116, VM216, VM316, HV116, and SA116.
  • the system state acquisition unit SA122 has a function of receiving system states from the monitoring result notification units A116, A216, A316, VM116, VM216, VM316, HV116, and SA116.
  • the monitoring configuration storage unit SA123 has a function of storing a monitoring configuration including trust chain configuration patterns of multiple multilayer monitoring units.
  • the monitoring change rule storage unit SA124 has a function of storing monitoring change rules including rules for changing the priority and monitoring configuration included in the monitoring information according to the system state.
  • the monitoring information changing unit SA125 has a function of requesting the monitoring information updating unit SA115 to change the monitoring information.
  • the monitoring server communication unit SA126 notifies the monitoring server 10 of the monitoring results, receives requests from the monitoring server 10 for changes in monitoring information, changes in the monitoring configuration, and changes in monitoring change rules, and has a function of responding to the requests. have.
  • the SA monitoring unit SA110 can monitor the external virtual machine VM100, the control virtual machine VM200, the video virtual machine VM300, and the software in the HV area. status can be obtained. Also, the SA management unit SA120 can change the monitoring configuration and monitoring information appropriately according to the system state.
  • FIG. 13 is a diagram illustrating a configuration diagram of a monitoring server according to Embodiment 1 of the present disclosure
  • the monitoring server 10 includes an in-vehicle system communication unit 11, a monitoring result display unit 12, a monitoring configuration changing unit 13, a monitoring change rule changing unit 14, and a monitoring information changing unit 15.
  • the in-vehicle system communication unit 11 has a function of communicating with the external communication unit A101 of the in-vehicle system 20.
  • the monitoring result display unit 12 has a function of receiving monitoring results from the external communication unit A101 of the in-vehicle system 20 via the in-vehicle system communication unit 11 and displaying information on the monitoring results on a graphical user interface.
  • the monitoring configuration change unit 13 accepts changes in the monitoring configuration and transmits a change request to the monitoring server communication unit SA126.
  • the monitoring change rule changing unit 14 accepts changes to the monitoring change rules and transmits a change request to the monitoring server communication unit SA126.
  • the monitoring information changing unit 15 accepts changes in monitoring information and transmits a change request to the monitoring server communication unit SA126.
  • Example of monitoring information 14 and 15 are diagrams showing examples of monitoring information.
  • the monitoring information contains information for each of the multi-layered monitoring units to confirm their own monitoring targets and monitor software and communication logs.
  • the monitoring information consists of a number, a person in charge of monitoring, a monitoring target, a memory address, an expected value, and a priority. Numbers are used to identify monitoring information.
  • the person in charge of monitoring is used to recognize the subject who monitors the monitoring target.
  • the monitoring target is used to recognize software and communication logs to be monitored.
  • the memory address is used to recognize the memory address where the target is stored in order to retrieve the target. Expected values are used to recognize normal values of information about monitored objects.
  • the priority is used to more intensively monitor a monitoring target with a higher priority. Details of the priority will be described later.
  • the application monitoring unit A110 is an external application monitoring unit
  • the application monitoring unit A210 is a control application monitoring unit
  • the application monitoring unit A310 is a video application monitoring unit
  • the VM monitoring unit VM110 is an external VM monitoring unit
  • the VM monitoring unit VM210 is a control VM.
  • Monitoring unit, VM monitoring unit VM310 is described as a video VM monitoring unit, and this description may also be used below.
  • the monitoring charge is the external VM monitoring unit
  • the monitoring target is the VM program 1
  • the memory address is the VM area B10
  • the expected value is B10
  • the priority is high.
  • the monitoring information numbered 15 has the control VM monitoring unit as the monitoring manager, the hypercall as the monitoring target, the memory address as "-", the expected value as "-”, and the priority The degree is "-”. This indicates that the control VM monitoring unit monitors hypercalls, but does not need to specify memory addresses, expected values, and priorities.
  • abnormalities can be determined using, for example, the permission list, the denial list, and normal statistical information.
  • each of the multi-layered monitoring units can confirm its own monitoring targets and monitor software and communication logs.
  • the software of the multi-layered monitoring unit in the monitoring target, it is possible to construct a trust chain for the monitoring of the multi-layered monitoring unit.
  • the SA monitoring unit SA110 monitors the software of the HV monitoring unit HV110
  • the HV monitoring unit HV110 monitors the software of the VM monitoring unit VM210
  • the VM monitoring unit VM210 monitors the software of the VM monitoring unit VM110 and the VM monitoring unit VM310.
  • the VM monitoring unit VM110 monitors the software of the application monitoring unit A110
  • the VM monitoring unit VM210 monitors the software of the application monitoring unit A110
  • the VM monitoring unit VM310 monitors the software of the application monitoring unit A310.
  • the multilayer monitoring unit is connected from the reliable SA monitoring unit SA110 to the application monitoring unit, and a trust chain for monitoring can be constructed.
  • FIG. 15 describes information for changing the software monitoring method according to the priority.
  • it consists of a priority, a monitoring cycle (minutes), a verification method, and a monitoring target selection method.
  • a priority a priority
  • a monitoring cycle minutes
  • a verification method a monitoring target selection method.
  • the monitoring period minutes
  • the verification method is used to recognize how to perform the monitoring process of the monitored object.
  • the monitoring target selection method is used to recognize a selection method when there are multiple monitoring targets.
  • the monitoring period minutes
  • the verification method is replication value
  • the monitoring target selection method is fixed. This indicates validating a fixed target with duplicate values at 1 minute intervals.
  • Fixing means monitoring all predetermined monitoring targets
  • replication value means verifying using the raw data of the monitoring targets stored in memory.
  • the priority is medium, it indicates that the monitoring targets are to be verified in a specific order at 10-minute intervals using not the duplicated values but the masked values obtained by masking the duplicated values.
  • the priority indicates that the monitoring targets are verified in random order at intervals of 100 minutes using the hash value of the replicated value.
  • the memory area may be divided into two or more blocks, and the divided blocks may be randomly selected and monitored. Thereby, the processing load can be reduced.
  • a specific monitoring cycle may be set, and monitoring may be performed during the idle time of the CPU after the timing of the cycle, instead of immediately performing the monitoring when the cycle arrives.
  • the monitoring timing differs each time, the load on the system where real-time performance is emphasized can be reduced.
  • a period during which at least one monitoring is performed may be set.
  • monitoring can be performed by utilizing idle time of the CPU during a predetermined period.
  • monitoring timing may be defined according to specific events or verification results of specific monitoring units.
  • the software of the application monitoring unit A110 may be monitored at the timing of Internet connection
  • the software of the control virtual machine may be monitored at the timing when the driving state of the vehicle is changed to automatic driving
  • the security abnormality may be monitored. It is possible to monitor the software of the multi-layered monitoring unit related to the abnormality at the timing when is determined once, or to monitor the software of the connected monitoring unit at the timing when the security is determined to be normal twice without an abnormality. .
  • the area containing the log may be specified in the memory address, the permission list may be specified in the expected value, and the priority may be specified.
  • the communication log monitoring method may also be changed according to the priority.
  • FIG. 16 is a diagram illustrating an example of system states.
  • the system state is used by the management unit SA120 to grasp the system state of the integrated ECU 200.
  • the system information consists of number, classification, system state, and parameter. Numbers are used to identify system states. There are four classifications, network, VM, security, and vehicle, which are used to classify the system state.
  • the system state describes the name of a specific system state, and the parameter describes a parameter for specifying the system state.
  • the system state numbered 5 is classified as VM, the system state is VM state, and the parameter is a VM identifier, one of on, off, and restarting, and time.
  • the parameters include an identifier that identifies the specific virtual machine, the state of being restarted, and the time when the state was determined. be done.
  • the system state with the number 1 is checked, the state of whether or not the integrated ECU 200 is connected to the Internet can be grasped, and the system state with the number 9 can be checked with the running state of the vehicle. , it is possible to grasp the state of automatic operation or not, and if the system state whose number is 7 is confirmed, it is possible to grasp the information of the software to be monitored that is determined to be abnormal as a result of the software verification.
  • the system state in FIG. 16 shows a list of system states and items to be described in the parameters.
  • Example of monitoring configuration 17 to 20 are diagrams showing examples of monitoring configurations.
  • a monitoring configuration is used to connect multiple monitoring units and change the monitoring trust chain.
  • the monitoring configuration consists of a number and a monitoring configuration.
  • the number is used to identify the monitoring configuration, and the monitoring configuration describes the connection pattern of the multi-layer monitoring units.
  • the software of the VM monitoring unit VM310 is monitored, the VM monitoring unit VM110 monitors the software of the application monitoring unit A110, the VM monitoring unit VM210 monitors the software of the application monitoring unit A110, and the VM monitoring unit VM310 monitors the software of the application monitoring unit A310.
  • the multi-layered monitoring unit is connected from the reliable SA monitoring unit SA110 to the application monitoring unit, and a trust chain for monitoring can be constructed.
  • control virtual machine VM200 since the control virtual machine VM200 is not directly connected to the external network, it can be assumed to be more reliable than the external virtual machine VM100, so it can be treated as a monitoring unit with higher reliability.
  • the monitoring configuration of number 2 in FIG. 17 is the same as the management configuration of number 1 except that the SA monitoring unit SA110 monitors the software of the VM monitoring unit VM210 instead of the HV monitoring unit HV110.
  • the processing and program complexity of the SA monitoring part SA110 increase, but by monitoring from the reliable SA monitoring part SA110, the reliability of the software of the VM monitoring part VM210 is increased. can be done.
  • the monitoring configuration of number 3 in FIG. 18 is a monitoring configuration that can maintain trust chain monitoring of monitoring even when the control virtual machine VM200 goes down. If the monitoring configuration of number 1 or number 2 is continued when the control virtual machine VM200 goes down, the person in charge of monitoring the VM monitoring unit VM110 or the VM monitoring unit VM310 will be absent, and the trust chain for monitoring will be broken. can't keep up.
  • the application This is a monitoring configuration capable of maintaining trust chain monitoring of monitoring other than the monitoring unit A210. If the monitoring configuration of number 1 or number 2 is continued when a security abnormality is detected in the control virtual machine VM200, the control virtual VM machine 210 is in charge of monitoring the software of the VM monitoring unit VM110 and the VM monitoring unit VM310. However, since the control virtual machine VM200 is highly likely to be tampered with, the monitoring trust chain cannot be maintained.
  • the monitoring configuration of number 5 in FIG. 19 is a monitoring configuration that can enhance monitoring when an abnormality is detected in the control virtual machine VM200 or when the risk of tampering with the control virtual machine VM200 is high.
  • the frequency and reliability of monitoring can be increased.
  • the monitoring result of the SA monitoring unit SA110 which has a high degree of reliability, can be adopted.
  • the VM monitoring unit VM210 is completely removed from the monitoring unit, and the application monitoring unit is added to the other virtual machine monitoring unit.
  • the monitoring configuration of A110 it is a monitoring configuration that can maintain the trust chain monitoring of monitoring. If the monitoring configuration of number 1 or number 2 is continued when a security abnormality is detected in the control virtual machine VM200, the control virtual machine VM200 is in charge of monitoring the software of the VM monitoring unit VM110 and the VM monitoring unit VM310. , the control virtual machine VM200 is highly likely to be tampered with, so the monitoring trust chain cannot be maintained.
  • the monitoring configuration of number 7 in FIG. 20 is a monitoring configuration that can strengthen monitoring when there is a high possibility that the external virtual machine VM100 will be tampered with, such as in the Internet connection state.
  • the frequency and reliability of monitoring can be increased.
  • the monitoring result of the HV monitoring unit HV110 with high reliability can be adopted.
  • the VM monitoring unit VM210 monitors the software of the VM monitoring unit VM310
  • the VM monitoring unit VM310 monitors the software of the VM monitoring unit VM110
  • the VM monitoring unit VM110 monitors the software of the VM monitoring unit VM210, or a mutual monitoring configuration in which each virtual machine monitoring unit monitors the software of the other virtual machine monitoring units.
  • the monitoring configuration may be dynamically calculated and changed.
  • the monitoring configuration is stored as a directed graph in which the monitoring unit is the vertex, the person in charge of monitoring is the starting point of the road, and the monitoring target is the ending point of the road, and the monitoring configuration is changed by reconstructing the directed graph using a predetermined algorithm.
  • the monitoring configuration is stored as a tree structure in which the monitoring unit is a node, the person in charge of monitoring is a parent node, and the monitoring target is a child node, and the tree structure is reconstructed by a predetermined algorithm. can be changed.
  • FIG. 21 is a diagram showing an example of a monitoring change rule.
  • the monitoring change rule is used by the management unit SA120 to change the priority of monitoring information and the monitoring configuration according to the system state.
  • the monitoring change rule consists of a number, change conditions, and change processing.
  • the number is used to identify the supervision change rule.
  • the change condition is used to determine whether the system state is to perform change processing.
  • the change process describes changes to the monitoring configuration.
  • the change condition is Internet connection establishment
  • the change process is to temporarily raise the monitoring priority of the VM monitor VM110 and the application monitor A110.
  • the change process is to temporarily raise the monitoring priority of the VM monitor VM110 and the application monitor A110.
  • a monitoring change rule with a number of 10 when an abnormality occurs in a specific communication, there is a high possibility that an abnormality has occurred in the source software, and the destination software may be attacked. Since there is a high possibility that the monitoring unit that has determined a communication abnormality will also be invalidated, it is possible to focus on monitoring by raising the priority of each. Furthermore, by changing the monitoring configuration, it is possible to monitor software that is highly likely to be tampered with by a plurality of monitoring units.
  • a virtual machine monitoring unit that operates on a virtual machine with a low CPU usage rate performs monitoring, thereby reducing the burden on a system in which real-time performance is important.
  • the management unit SA120 determines whether an external network is being connected, the occurrence of an external network connection establishment event, the system state of the virtual machine, the monitoring result of the multi-layered monitoring unit, and the execution authority of the monitoring unit that has detected an abnormality.
  • the priority and monitoring configuration can be changed according to the execution authority of the software that detected the anomaly and the destination or sender of the communication log that detected the anomaly.
  • Example of monitoring result display 22 and 23 are diagrams showing an example of a monitor result display.
  • the monitoring result display is used by the monitoring server 10 to receive monitoring results from the in-vehicle system 20 and display the monitoring results on a graphical user interface to convey monitoring information to security analysts.
  • the monitoring result received from the in-vehicle system 20 is the same as the item of classification security of the system state, but if the software is normal, the identifier identifying the monitoring unit and the identifier identifying the software to be monitored are included. , the time when it was determined to be normal, and if the software was abnormal, an identifier that identifies the monitoring unit, an identifier that identifies the software to be monitored, and the time when it was determined to be abnormal, and if the communication log is normal If there is an error in the communication log, it contains an identifier that identifies the monitoring unit, an identifier that identifies the communication protocol, a normal communication message, and the time when it was determined to be normal.
  • a vehicle ID for identifying the vehicle and an ECUID for identifying the ECU may be added to the monitoring result and transmitted to the monitoring server 10 .
  • FIG. 22 an abstracted system architecture of the integrated ECU 200 is displayed, abnormal and normal components are emphasized and expressed so that they can be distinguished, and corresponding monitoring results are displayed below the components. ing. As a result, it is possible to intuitively understand the component in which an abnormality has occurred during security analysis, so that security abnormality analysis can be performed quickly.
  • buttons for changing the monitoring configuration and changing the monitoring information are arranged at the bottom of the graphical user interface.
  • FIG. 24 is a diagram illustrating a sequence of monitoring processing by an application monitoring unit according to Embodiment 1 of the present disclosure.
  • FIG. 24 It shows the processing sequence from when the monitoring target acquisition unit A111 of the application monitoring unit A110 acquires the external communication log and the hash value of the software (SW) in the application area to notifying the SA121 of the monitoring result.
  • the external application A100 will be described as an example, but the control application A200 and the video application A300 have the same processing sequence except for the types of communication logs, so the description is omitted.
  • the monitoring target acquisition unit A111 of the application monitoring unit A110 acquires a communication log, which is an external communication log, from the external communication unit A101 and transmits it to the monitoring unit A113.
  • the monitoring unit A113 determines whether the communication log contains an abnormality, and notifies the monitoring result notification unit A116 of the monitoring result.
  • the monitoring result includes an identifier that identifies the monitoring unit, an identifier that identifies the software to be monitored, and the determination time. contains an identifier that identifies the monitoring unit, an identifier that identifies the software to be monitored, and the determination time; if the communication is normal, an identifier that identifies the monitoring unit and an identifier that identifies the communication protocol and the decision time.
  • the monitoring result notification unit A116 notifies the monitoring result acquisition unit SA121 of the monitoring result.
  • the monitoring result acquisition unit SA121 acquires the monitoring result.
  • the monitoring target acquisition unit A111 acquires the hash value of the software stored in the application area storage unit A103 each time a certain period of time elapses according to the priority of the monitoring target described in the monitoring information storage unit A114. Then, the expected value of the hash value of the software stored in the monitoring information storage unit A114 is obtained and transmitted to the monitoring unit A113.
  • the monitoring unit A113 determines that it is normal, and if they do not match, determines that it is abnormal, and notifies the monitoring result notification unit A116 of the monitoring result.
  • the monitoring result notification unit A116 notifies the monitoring result acquisition unit SA121 of the monitoring result.
  • the monitoring result acquisition unit SA121 acquires the monitoring result.
  • FIG. 25 is a diagram illustrating a sequence of monitoring processing by a virtual machine monitoring unit according to Embodiment 1 of the present disclosure.
  • FIG. 10 shows a processing sequence from when a monitoring target acquisition unit VM211 of a VM monitoring unit VM210 acquires system calls, hypercalls, software in an application area, and hash values of software in a VM area to notifying a monitoring result to an SA 121.
  • the VM monitoring unit VM210 will be described as an example, but the VM monitoring unit VM110 and the VM monitoring unit VM310 have the same processing sequence except that they do not acquire hypercalls, so the description is omitted.
  • the monitoring target acquisition unit VM211 of the VM monitoring unit VM210 acquires communication logs of system calls and hyper calls from the system call control unit VM202 and the hyper call control unit HV102 of the hypervisor HV100, respectively, and transmits them to the monitoring unit VM213. do.
  • the monitoring unit VM 213 determines whether the communication log contains an abnormality, and notifies the monitoring result notification unit VM 216 of the monitoring result.
  • the monitoring result notification unit VM216 notifies the monitoring result acquisition unit SA121 of the monitoring result.
  • the monitoring result acquisition unit SA121 acquires the monitoring result.
  • the monitoring target acquisition unit VM211 updates the software stored in the VM area storage units VM103, 203, and 303 each time a certain period of time elapses according to the priority of the monitoring target described in the monitoring information storage unit VM214.
  • a hash value is acquired, an expected value of the hash value of the software stored in the monitoring information storage unit VM214 is acquired, and the expected value is transmitted to the monitoring unit VM213.
  • the monitoring unit VM 213 determines that it is normal, and if they do not match, determines that it is abnormal, and notifies the monitoring result notification unit HV 116 of the monitoring result.
  • the monitoring result notification unit VM216 notifies the monitoring result acquisition unit SA121 of the monitoring result.
  • the monitoring result acquisition unit SA121 acquires the monitoring result.
  • FIG. 26 is a diagram illustrating a sequence of a hypervisor monitoring process according to the first embodiment of the present disclosure
  • the monitoring target acquisition unit HV111 of the HV monitoring unit HV110 acquires the VM area storage units VM103, 203, and 303 each time a certain period of time elapses according to the priority of the monitoring target described in the monitoring information storage unit HV114.
  • the hash value of the software stored in the HV area storage unit HV103 is acquired, the expected value of the hash value of the software stored in the monitoring information storage unit HV114 is acquired, and transmitted to the monitoring unit HV113.
  • the monitoring unit HV113 determines that it is normal when the obtained value and the expected value match, and determines that it is abnormal when they do not match, and notifies the monitoring result notification unit HV116 of the monitoring result.
  • the monitoring result notification unit HV116 notifies the monitoring result acquisition unit SA121 of the monitoring result.
  • the monitoring result acquisition unit SA121 acquires the monitoring result.
  • FIG. 27 is a diagram illustrating a sequence of secure application monitoring processing according to the first embodiment of the present disclosure.
  • It shows the processing sequence from when the monitoring target acquiring unit SA111 of the SA monitoring unit SA110 acquires the hash values of the software in the VM area and the software in the HV area to notifying the SA121 of the monitoring result.
  • the monitoring target acquisition unit SA111 of the SA monitoring unit SA110 according to the priority of the monitoring target described in the monitoring information storage unit SA114, each time a certain period of time elapses,
  • the hash value of the software stored in the HV area storage unit HV103 is acquired, the expected value of the hash value of the software stored in the monitoring information storage unit SA114 is acquired, and transmitted to the monitoring unit SA113.
  • the monitoring unit SA113 determines normal if the acquired value and the expected value match, and determines abnormal if they do not match, and notifies the monitoring result notification unit SA116 of the monitoring result.
  • the monitoring result notification unit SA116 notifies the monitoring result acquisition unit SA121 of the monitoring result.
  • the monitoring result acquisition unit SA121 acquires the monitoring result.
  • FIG. 28 is a diagram illustrating a sequence of monitoring server notification processing according to Embodiment 1 of the present disclosure.
  • the monitoring result acquisition unit SA121 of the SA monitoring unit SA110 acquires the monitoring results from the application monitoring unit, the virtual machine monitoring unit, the HV monitoring unit HV110, and the SA monitoring unit SA110, and the monitoring result display unit 12 of the monitoring server 10 acquires the monitoring results. It shows the processing sequence up to display.
  • the monitoring result acquisition unit SA121 of the SA monitoring unit SA110 acquires monitoring results from the application monitoring unit, virtual machine monitoring unit, HV monitoring unit HV110, and SA monitoring unit SA110, and transmits them to the monitoring server communication unit SA126.
  • the monitoring server communication unit SA126 notifies the in-vehicle system communication unit 11 of the monitoring server 10 of the monitoring result via the external communication unit A101.
  • the in-vehicle system communication unit 11 receives the monitoring result and transmits it to the monitoring result display unit 12.
  • the monitoring result display unit 12 displays the monitoring result.
  • FIG. 29 is a diagram illustrating a sequence of monitoring information change processing according to Embodiment 1 of the present disclosure.
  • the system status acquisition part SA122 of the SA monitoring part SA110 acquires the security status from the application monitoring part, the virtual machine monitoring part, the HV monitoring part HV110, and the SA monitoring part SA110. , the processing sequence until the monitoring information of the SA monitoring unit SA110 is updated.
  • the system state acquisition unit SA122 of the SA monitoring unit SA110 acquires security states from the application monitoring unit, virtual machine monitoring unit, HV monitoring unit HV110, and SA monitoring unit SA110, and transmits them to the monitoring information changing unit SA125.
  • the monitoring information change unit SA125 checks the monitoring change rule stored in the monitoring change rule storage unit SA124, and if the system state matches the change condition of the monitoring change rule, performs change processing and updates the monitoring information. A change is requested to parts A115, A215, A315, VM115, VM215, VM315, HV115, and SA115.
  • the monitoring information update units A115, A215, A315, VM115, VM215, VM315, HV115, and SA115 update the monitoring information.
  • the monitoring information and monitoring configuration can also be changed from the monitoring server 10.
  • the monitoring server communication unit SA126 receives the change information from the monitoring server 10 and transmits it to the monitoring information change unit SA125.
  • the monitoring information change unit SA125 updates the configuration information contained in the monitoring configuration storage unit SA123, and requests the monitoring information update units A115, A215, A315, VM115, VM215, VM315, HV115, and SA115 to change the monitoring information. It will be realized by doing.
  • FIG. 30 shows a flowchart of monitoring processing according to the first embodiment of the present disclosure.
  • the application monitoring unit A110 will be described as an example. are the same except that
  • the monitoring target acquisition unit A111 of the application monitoring unit A110 acquires the hash value of the external communication log and software to be monitored, and executes S3002 and S3005.
  • the monitoring unit A113 determines whether or not the external communication log acquired in S3001 contains an abnormality, executes S3003 when an abnormality is contained, and executes S3004 when an abnormality is not contained.
  • the monitoring unit A113 determines that the communication to be monitored is abnormal, updates the system state, and executes S3005.
  • the monitoring unit A113 updates the system state assuming that the communication to be monitored is normal, and executes S3005.
  • the monitoring result notification unit A116 notifies the monitoring result acquisition unit SA121 of the monitoring result and the system state, and terminates.
  • the monitoring unit A113 determines whether the software contains an abnormality.
  • the monitoring unit A113 determines that the software to be monitored is abnormal, updates the system status, and executes S3005.
  • the monitoring unit A113 determines that the software to be monitored is normal, updates the system state, and executes S3005.
  • FIG. 31 shows a flowchart of monitoring change processing according to the first embodiment of the present disclosure.
  • the system state acquisition unit SA122 of the management unit SA120 acquires the system state and executes S3102.
  • the monitoring information change unit SA125 checks the monitoring change rule stored in the monitoring change rule storage unit SA124, determines whether the system state acquired in S3101 matches the change condition of the monitoring change rule, If they match, S3103 is executed, and if they do not match, the process ends.
  • the monitoring information change unit SA125 executes the change processing described in the monitoring change rule matched in S3102, and monitors the monitoring information update units A115, A215, A315, VM115, VM215, VM315, HV115, and SA115. Request a change of information and exit.
  • FIG. 32 is a diagram showing a detailed modified example 1 of the configuration diagram of the integrated ECU according to the first embodiment of the present disclosure.
  • FIG. 4 assumes that the type 1 hypervisor HV100 is used as the virtual software platform, but the type 2 hypervisor HV200 may also be used. In this case, the host operating system HOS100 activates the hypervisor HV200, and the hypervisor HV200 activates the virtual machine.
  • the hypervisor HV200 includes an HV monitoring unit HV210 that monitors software in the HV area and software in the VM area, and the host operating system HOS100 monitors software in the host OS area, software in the HV area, software in the VM area, and system calls.
  • HV monitoring unit HV210 that monitors software in the HV area and software in the VM area
  • HOS100 monitors software in the host OS area, software in the HV area, software in the VM area, and system calls.
  • a host OS monitoring unit HOS110 is provided.
  • the secure operating system is assigned the most secure execution rights (PL4) and the applications on the operating system are assigned the next most secure execution rights (PL3).
  • the host operating system HOS100 is assigned a strong execution privilege (PL1), and the hypervisor HV200 and the virtual machine are assigned the same execution privilege (PL1) as the host operating system HOS100.
  • the weakest execution authority is assigned to the application (PL0) on the virtual machine.
  • the external application A100 which is connected to the external network, is most likely to be tampered with and has the lowest reliability. It can be assumed that the external virtual machine VM100 with weak authority, the control virtual machine VM200, the video virtual machine VM300, the hypervisor HV200, and the host operating system HOS100 have low reliability, and the secure application SA100 and the secure operating system SOS100 have the highest reliability. Also, when the host operating system HOS100 provides an external network interface to the external virtual machine by means of a bridge or the like, the host operating system HOS100 may be connected to the external network, and the host operating system HOS100 provides the virtual machine with an external network interface. Since there is a possibility that the storage can be accessed, unlike the hypervisor HV200 in FIG. 4, the reliability of the software is low. Therefore, it is desirable to monitor not only the host operating system HOS100 but also the hypervisor HV200 and virtual machine software from the secure application.
  • the SA monitoring part SA110 may monitor the software of the host OS monitoring part HOS110, the software of the HV monitoring part HV210, and the software of the virtual machine, and the virtual machine monitoring part may monitor the application monitoring part.
  • hypervisor HV200 may be assigned a stronger execution authority (PL2) than the host operating system HOS100.
  • execution authority PL2
  • reliability the same as those described in FIG.
  • FIG. 33 is a diagram showing a detailed modification 2 of the configuration diagram of the integrated ECU according to the first embodiment of the present disclosure.
  • FIG. 4 shows that the hypervisor HV100 executes and monitors three types of virtual machines. It can be assumed that the layers are virtualized to operate the container application CA100 and the container application CA200.
  • the container virtual machine VM400 includes a VM monitoring unit VM410 that monitors the software in the VM area including the software of the container engine CE100, the software and settings of the container application CA100, and the software and settings of the container application CA200. It includes software in the application area, a container application CA100, and a container application monitoring unit CA210 that monitors inter-container communication.
  • the secure operating system is assigned the strongest secure execution privilege (PL4)
  • the applications on the operating system are assigned the next strongest secure execution privilege (PL3)
  • the hypervisor HV100 is assigned the next strongest execution privilege (PL3).
  • the weakest execution authority is assigned to the container engine CE100, the container application CA100, and the container application CA200.
  • the container application CA100 has a function to communicate with a proximity network such as Wi-Fi or Bluetooth, and the container application CA200 has a vehicle control function, considering the possibility of software tampering, the container application CA100 The reliability of the container application CA200 is considered to be high.
  • a trust chain for monitoring can be established even between containers operating with the same execution authority.
  • the external application A100 which is connected to the external network, is most likely to be tampered with, so it has the lowest reliability. is the second lowest, the container application CA100 which has the same execution authority but does not directly communicate via the network, the container engine CE100 which has the lowest reliability, the next lowest execution authority is the external virtual machine VM100, and the container virtual machine VM100. It can be assumed that the reliability of the machine VM400 is low, followed by the hypervisor HV100 with the weakest execution authority, the secure application SA100, and the secure operating system SOS100, which have the highest reliability.
  • the SA monitoring unit SA110 monitors the software of the HV monitoring unit HV110 and the software of the virtual machine
  • the VM monitoring unit VM410 monitors the container engine CE100, the container application CA100, the container application CA200, and the container application monitoring unit CA210.
  • the container application monitoring unit CA210 monitors the application monitoring software, the container application CA100, and the inter-container communication. can be supervised from at least one multi-layer supervisor operating with stronger execution authority or higher trust, thus building a chain of trust for supervision.
  • hypervisor HV100 is not essential, and the host operating system may virtualize the application using the container engine CE100 to operate the container application CA100 and the container application CA200.
  • the execution authority, reliability, and monitoring trust chain are the same as those described in FIG. 33 by deleting the hypervisor HV100 and replacing it with the operating system that hosts the container virtual machine VM400.
  • Embodiment 1 has been described as an example of the technology according to the present disclosure.
  • the technology according to the present disclosure is not limited to this, and can also be applied to embodiments in which changes, replacements, additions, omissions, etc. are made as appropriate.
  • the following modifications are also included in one embodiment of the present disclosure.
  • the security measures for the in-vehicle system installed in the vehicle have been explained, but the scope of application is not limited to this. It may be applied not only to automobiles but also to mobility such as construction machines, agricultural machines, ships, railroads, and airplanes. That is, it can be applied as a security measure in a mobility system. It may also be applied to industrial control systems such as factories and buildings.
  • a secure monitor call used for secure application communication is not used as a communication log, but the VM monitoring unit VM210, the HV monitoring unit HV110, or the SA monitoring unit SA110 may be monitored. . This has the effect of supplementing attempted attacks on confidential information stored in secure applications and secure OSs.
  • the hypervisor HV 100 executes and manages three types of virtual machines. It may be a virtual machine.
  • the reliability of the virtual machine varies depending on whether or not there is a connection to an external network or whether or not there is a vehicle control function.
  • the reliability of the virtual machine may differ depending on the presence or absence of the third-party application download function. In this case, if it has a user login function, there is a possibility of unauthorized login, so the reliability is low. can be assumed to be low.
  • all virtual machines, all applications, the hypervisor HV100, and the secure application SA100 are provided with monitoring units. It suffices that two or more monitoring units having different degrees of reliability of the virtual machines are arranged.
  • a part or all of the components constituting each device in the above embodiments may be configured from one system LSI (Large Scale Integration).
  • a system LSI is an ultra-multifunctional LSI manufactured by integrating multiple components on a single chip. Specifically, it is a computer system that includes a microprocessor, ROM, RAM, etc. . A computer program is recorded in the RAM. The system LSI achieves its functions by the microprocessor operating according to the computer program. Further, each part of the constituent elements constituting each of the above devices may be individually integrated into one chip, or may be integrated into one chip so as to include part or all of them.
  • system LSI may also be called IC, LSI, super LSI, or ultra LSI depending on the degree of integration.
  • the method of circuit integration is not limited to LSI, and may be realized by a dedicated circuit or a general-purpose processor.
  • An FPGA Field Programmable Gate Array
  • a reconfigurable processor that can reconfigure the connections and settings of the circuit cells inside the LSI may be used.
  • an integration technology that replaces the LSI appears due to advances in semiconductor technology or another derived technology, the technology may naturally be used to integrate the functional blocks. Application of biotechnology, etc. is possible.
  • a part or all of the components that make up each device described above may be configured from an IC card or a single module that can be attached to and removed from each device.
  • An IC card or module is a computer system composed of a microprocessor, ROM, RAM and the like.
  • the IC card or module may include the super multifunctional LSI.
  • the IC card or module achieves its function by the microprocessor operating according to the computer program. This IC card or this module may have tamper resistance.
  • the present disclosure may be a program (computer program) that implements an abnormality detection method by a computer, or it may be a digital signal composed of a computer program.
  • computer-readable recording media such as flexible discs, hard disks, CD-ROMs, MOs, DVDs, DVD-ROMs, DVD-RAMs, BDs (Blue - ray (registered trademark) Disc), semiconductor memory or the like.
  • it may be a digital signal recorded on these recording media.
  • the computer program or digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network represented by the Internet, data broadcasting, or the like.
  • one aspect of the present disclosure may be a computer system including a microprocessor and memory, the memory recording the computer program, and the microprocessor operating according to the computer program.
  • the program or digital signal may be recorded on a recording medium and transferred, or the program or digital signal may be transferred via a network or the like to be implemented by another independent computer system.
  • the monitoring device of the present disclosure even if an attacker intrudes into an in-vehicle system and tampered with and invalidates a monitoring program implemented in a low-reliability area, an abnormality occurring in the in-vehicle system can be detected. detectable.
  • the aim is to provide safe automated driving and advanced driver assistance systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Automation & Control Theory (AREA)
  • Quality & Reliability (AREA)
  • Mathematical Physics (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Human Computer Interaction (AREA)
  • Debugging And Monitoring (AREA)

Abstract

信頼可能な領域に実装された第一の監視プログラムから、信頼度が低い領域に実装された第二のセキュリティ対策機構を監視し、第二のセキュリティ対策機構から監視対象を監視することで、第二のセキュリティ対策機構の監視結果の信頼度を高めることができる。つまり、信頼度の低い第二のセキュリティ対策機構が改ざんされた場合であっても、第一のセキュリティ対策機構から改ざんを検知でき、ＥＣＵに発生している異常を検知できるため、安全な自動運転や先進運転支援システムを提供することができる。

Description

監視装置、監視システムおよび監視方法
　本開示は、監視装置および監視方法に関する。
　近年、自動運転などの先進機能を利用者へ提供するため、車載システムが複雑化している。複雑化に伴って増大する開発期間やコストの課題を解消するため、従来複数のＥＣＵ（Ｅｌｅｃｔｒｏｎｉｃ　Ｃｏｎｔｒｏｌ　Ｕｎｉｔ）に分かれて搭載されていた機能を１つのＥＣＵへ統合する動きがある。ＥＣＵの統合において、１つのＥＣＵに複数の仮想的なコンピュータを動作させるために仮想化技術が利用されており、その仮想的なコンピュータは仮想マシンと呼ばれ、複数の仮想マシンを動作させる仮想化基盤となるソフトウェアはハイパーバイザと呼ばれる。
　ハイパーバイザ内の仮想化ソフトウェアまたはデバイスドライバに含まれる脆弱性や仕様の不具合が顕著化した場合、ハイパーバイザまたは仮想マシンに割り当てられるメモリ領域の改ざんがなされ得るという問題がある。その対策として、特許文献１には、仮想化ソフトウェア上に、監視用の仮想マシンと監視対象となる仮想マシンを配置し、監視用の仮想マシンから監視対象を監視することで、監視対象における異常を検知する方法が記載されている。
特開２０１９－１４４７８５号公報
　ところで、車両システムにおいて、第三者のアプリケーションを自由にインストール可能なＩＶＩ（Ｉｎ－Ｖｅｈｉｃｌｅ　Ｉｆｏｒｔａｉｎｍｅｎｔ）システムと、車両の走る、止まる、曲がるなどの制御を指示することで自動運転を支援するＡＤＡＳ（Ａｄｖａｎｃｅｄ　Ｄｒｉｖｅｒ　Ａｓｓｉｓｔａｎｃｅ　Ｓｙｓｔｅｍ）システムを１つのＥＣＵに統合する場合、第三者の悪意のあるアプリケーションによってＡＤＡＳ制御方法に関連するメモリ領域が改ざんされると、搭乗者の安全を脅かす重大な問題となる。
　しかしながら、特許文献１の方法は、監視用の仮想マシンが改ざんされていない場合は監視対象の異常を検知可能であるが、監視用の仮想マシン自体が第三者の悪意のあるアプリケーションによって改ざんされた場合は、異常を検知できない課題がある。
　本開示は、従来の課題を解決するもので、信頼可能な領域に実装された第一のセキュリティ対策機構から、信頼度が低い領域に実装された第二のセキュリティ対策機構を監視し、第二の監視プログラムから監視対象を監視することで、第二のセキュリティ対策機構の監視結果の信頼度を高めることができる。つまり、信頼度の低い第二のセキュリティ対策機構が改ざんされた場合であっても、第一のセキュリティ対策機構から改ざんを検知できるため、ＥＣＵに発生している異常を検知できる。
　本開示の一態様に係る監視装置は、ソフトウェアと通信ログのうち少なくとも１つを監視対象として監視する２以上の監視部を備え、前記監視部は、それぞれ２種類の実行権限のうちいずれか一つの実行権限にて動作し、信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、第一の実行権限にて動作する第一の監視部は第二の実行権限にて動作する第二の監視部のソフトウェアを監視対象に含む、監視装置である。
　本開示の一態様に係る監視方法は、ソフトウェアと通信ログのうち少なくとも１つを監視対象として監視する２以上の監視ステップであって、前記監視ステップは、それぞれ２種類の実行権限のうちいずれか一つの実行権限にて実行され、信頼度の低い監視ステップを実行するソフトウェアを少なくとも１つの信頼度の高い監視ステップにて監視できるように、第一の実行権限にて実行される第一の監視ステップは第二の実行権限にて実行される第二の監視ステップを実行するソフトウェアを監視対象に含む、監視方法である。
　本開示の監視装置によれば、信頼度が低い領域に実装された監視プログラムが改ざんされた場合であっても、ＥＣＵに発生した異常を検知できる。
図１は、本開示の実施の形態における監視システムの全体構成図を示す図である。 図２は、本開示の実施の形態における車載システムの構成図を示す図である。 図３は、本開示の実施の形態における統合ＥＣＵの構成図を示す図である。 図４は、本開示の実施の形態における統合ＥＣＵの構成図の詳細を示す図である。 図５は、本開示の実施の形態における外部アプリの構成図を示す図である。 図６は、本開示の実施の形態における制御アプリの構成図を示す図である。 図７は、本開示の実施の形態における映像アプリの構成図を示す図である。 図８は、本開示の実施の形態における外部仮想マシンの構成図を示す図である。 図９は、本開示の実施の形態における制御仮想マシンの構成図を示す図である。 図１０は、本開示の実施の形態における映像仮想マシンの構成図を示す図である。 図１１は、本開示の実施の形態におけるハイパーバイザの構成図を示す図である。 図１２は、本開示の実施の形態におけるセキュアアプリの構成図を示す図である。 図１３は、本開示の実施の形態における監視サーバーの構成図を示す図である。 図１４は、本開示の実施の形態における監視情報の一例を示す図である。 図１５は、本開示の実施の形態における監視情報の一例を示す図である。 図１６は、本開示の実施の形態におけるシステム状態の一例を示す図である。 図１７は、本開示の実施の形態における監視構成の一例を示す図である。 図１８は、本開示の実施の形態における監視構成の一例を示す図である。 図１９は、本開示の実施の形態における監視構成の一例を示す図である。 図２０は、本開示の実施の形態における監視構成の一例を示す図である。 図２１は、本開示の実施の形態における監視変更ルールの一例を示す図である。 図２２は、本開示の実施の形態における監視結果表示の一例を示す図である。 図２３は、本開示の実施の形態における監視結果表示の一例を示す図である。 図２４は、本開示の実施の形態における、アプリ監視部の監視処理のシーケンスを示す図である。 図２５は、本開示の実施の形態における、ＶＭ監視部の監視処理のシーケンスを示す図である。 図２６は、本開示の実施の形態における、ＨＶ監視部の監視処理のシーケンスを示す図である。 図２７は、本開示の実施の形態における、ＳＡ監視部の監視処理のシーケンスを示す図である。 図２８は、本開示の実施の形態における、監視サーバー通知処理のシーケンスを示す図である。 図２９は、本開示の実施の形態における、管理部から監視変更する処理のシーケンスを示す図である。 図３０は、本開示の実施の形態における、監視処理のフローチャートを示す図である。 図３１は、本開示の実施の形態における、監視変更処理のフローチャートを示す図である。 図３２は、本開示の実施の形態における、統合ＥＣＵの構成図の詳細の変形例１を示す図である。 図３３は、本開示の実施の形態における、統合ＥＣＵの構成図の詳細の変形例２を示す図である。
　上記課題を解決するために、本開示の一態様に係る監視装置は、ソフトウェアと通信ログのうち少なくとも１つを監視対象として監視する２以上の監視部を備え、前記監視部は、それぞれ２種類の実行権限のうちいずれか一つの実行権限にて動作し、信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、第一の実行権限にて動作する第一の監視部は第二の実行権限にて動作する第二の監視部のソフトウェアを監視対象に含む、監視装置である。
　これにより、システムに侵入した攻撃者は弱い実行権限の獲得後、より強い実行権限の獲得を目指すと想定できるため、第一の実行権限よりも弱い第二の実行権限が乗っ取られた後、第二の監視部のソフトウェアを改ざんすることで監視を回避しようと試みた場合であっても、第一の監視部から、第二の監視部のソフトウェアの異常を検知できる効果がある。また、強い実行権限でプログラムを動作させる環境とは弱い実行権限でプログラムを動作させる環境は分離されると想定できるため、実行権限が異なる２段階の監視部を用いることによって、２種類の環境に渡って広い範囲の監視対象を監視できる効果がある。また、強い実行権限で動作するソフトウェアは脆弱性を含まないように単純なアルゴリズムで実装されると想定できるため、強い実行権限で動作する監視部には単純なアルゴリズムを採用し、弱い実行権限で動作する監視部には高度で複雑なアルゴリズムを採用できる効果がある。
　また、前記監視装置は、３以上の前記監視部を備え、前記監視部は、それぞれ３種類の実行権限のうちいずれか一つの実行権限にて動作し、信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、第一の実行権限にて動作する第一の監視部は第二の実行権限にて動作する監視部のソフトウェアを監視対象に含み、前記第一の監視部と前記第二の監視部のうち少なくとも１つは第三の実行権限にて動作する第三の監視部のソフトウェアを監視対象に含む、監視装置である。
　これにより、システムに侵入した攻撃者は弱い第三の実行権限を獲得後、より強い第二の実行権限、第一の実行権限の獲得を目指すと想定できるため、第二の実行権限よりも弱い第三の実行権限が乗っ取られた後、第三の監視部のソフトウェアを改ざんすることで監視を回避しようと試みた場合であっても、第一の監視部または第二の監視部から第三の監視部のソフトウェアの異常を検知できる効果がある。また、強い実行権限でプログラムを動作させる環境とは弱い実行権限でプログラムを動作させる環境は分離されると想定できるため、実行権限が異なる３段階の監視部を用いることによって、３種類の環境に渡って広い範囲の監視対象を監視できる効果がある。また、強い実行権限で動作するソフトウェアは脆弱性を含まないように単純なアルゴリズムで実装されると想定できるため、強い実行権限で動作する監視部には単純なアルゴリズムを採用し、弱い実行権限で動作する監視部には高度で複雑なアルゴリズムを採用できる効果がある。
　また、前記監視装置は、４以上の前記監視部を備え、前記監視部は、それぞれ４種類の実行権限のうちいずれかの実行権限にて動作し、信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、第一の実行権限にて動作する第一の監視部は第二の実行権限にて動作する監視部のソフトウェアを監視対象に含み、前記第一の監視部と前記第二の監視部のうち少なくとも１つは第三の実行権限にて動作する第三の監視部のソフトウェアを監視対象に含み、前記第一の監視部と前記第二の監視部と前記第三の監視部のうち少なくとも１つは第四の実行権限にて動作する第四の監視部のソフトウェアを監視対象に含む、監視装置である。
　これにより、システムに侵入した攻撃者は弱い第四の実行権限を獲得後、より強い第三の実行権限、強い第二の実行権限、第一の実行権限の獲得を目指すと想定できるため、第三の実行権限よりも弱い第四の実行権限が乗っ取られた後、第四の監視部のソフトウェアを改ざんすることで監視を回避しようと試みた場合であっても、第一の監視部または第二の監視部、第三の監視部から第四の監視部のソフトウェアの異常を検知できる効果がある。また、強い実行権限でプログラムを動作させる環境とは弱い実行権限でプログラムを動作させる環境は分離されると想定できるため、実行権限が異なる４段階の監視部を用いることによって、４種類の環境に渡って広い範囲の監視対象を監視できる効果がある。また、強い実行権限で動作するソフトウェアは脆弱性を含まないように単純なアルゴリズムで実装されると想定できるため、強い実行権限で動作する監視部には単純なアルゴリズムを採用し、弱い実行権限で動作する監視部には高度で複雑なアルゴリズムを採用できる効果がある。
　また、前記監視装置は、セキュアアプリと仮想ソフトウェア基盤と２以上の仮想マシン上にて動作し、前記第一の実行権限は、セキュアアプリの実行権限、仮想ソフトウェア基盤の実行権限、仮想マシンのカーネル実行権限のうちの一つであり、前記第二の実行権限は、仮想ソフトウェア基盤の実行権限、仮想マシンのカーネル実行権限、仮想マシンのユーザ権限のうちの一つであり、前記第三の実行権限は、仮想マシンのカーネル実行権限、仮想マシンのユーザ権限うちの一つであり、前記第四の実行権限は、仮想マシンのユーザ権限である、監視装置である。
　これにより、仮想マシンのユーザアプリの脆弱性をついて仮想マシンのユーザ権限を獲得した攻撃者は、仮想マシンのカーネル権限、ハイパーバイザの実行権限、セキュアアプリの実行権限の獲得を目指すと想定できるため、仮想マシンのユーザ権限、仮想マシンのカーネル権限、ハイパーバイザの実行権限を乗っ取られた後、乗っ取った実行権限で動作する監視部のソフトウェアを改ざんして監視を回避しようと試みた場合であっても、より強い実行権限の監視部から弱い実行権限の監視部の異常を検知できる効果がある。また、セキュアアプリの実行権限やハイパーバイザの実行権限では、仮想マシンのユーザ空間のソフトウェアや、仮想マシンのユーザ空間のネットワークログ、仮想マシンのユーザ空間とカーネル空間の間のシステムコールといった通信ログの取得が困難であると想定できるため、実行権限ごとに監視部を分離することによって、より広い範囲の監視対象を監視できる効果ある。また、セキュアアプリの実行権限とハイパーバイザの実行権限、仮想マシンのカーネル権限で動作するソフトウェアは脆弱性を含まないように単純なアルゴリズムで実装されると想定できるため、強い実行権限で動作する監視部には単純なアルゴリズムを採用し、弱い実行権限で動作する監視部には高度で複雑なアルゴリズムを採用できる効果がある。
　また、前記監視装置は、仮想ソフトウェア基盤と２以上の仮想マシン上にて動作し、前記仮想マシンに割り当てられた実行権限にて動作する監視部が２以上存在する場合、第一の仮想マシンの監視部は、第二の仮想マシンの監視部のソフトウェアを監視対象に含み、前記第一の仮想マシンと前記第二の仮想マシンは、攻撃者によって改ざんされる可能性に応じて分類される、監視装置である。
　これにより、外部ネットワークからシステムに侵入し、外部ネットワークと接続される仮想マシンのユーザ権限およびカーネル権限を獲得した攻撃者は、他の仮想マシンの機能獲得を目指すと想定できるため、外部ネットワークと接続される改ざんリスクの高い第二の仮想マシンの監視部が乗っ取られた場合であっても、外部ネットワークと接続しない改ざんリスクの低い第一の仮想マシンの監視部から第二の仮想マシンの監視部のソフトウェアの異常を検知できる効果がある。また、車両の制御機能を有する仮想マシンは、改ざんされた場合の安全性への影響が大きく、攻撃者の対象になりやすいため、より信頼可能な仮想マシンの監視部から監視することで、安全性を維持できる効果がある。もしくは、車両の制御機能を有する仮想マシンは、外部ネットワークから隔離されており、高い機能安全レベルの要求を満たすためにセキュアな設計と実装が十分考慮されていると想定できるため、車両の制御機能を有する仮想マシンは信頼可能な第一の仮想マシンとして扱うことができる効果がある。また、実行権限だけを考慮すると、改ざんリスクの高い第二の監視マシンの監視部は、セキュアアプリまたはハイパーバイザの実行権限から監視する必要があるが、実行権限が同一である第一の監視マシンの監視部から第二の監視マシンの監視部を監視できるため、セキュアアプリの実行権限とハイパーバイザの実行権限で動作するソフトウェアを単純化できる効果がある。また、外部ネットワークからシステムに侵入し、特定の仮想マシンのユーザ権限およびカーネル権限を獲得した攻撃者は、他の仮想マシンの機能獲得を目指すと想定できるため、第一の仮想マシンの監視部と、第二の仮想マシンが相互監視または巡回監視を行うことによって、特定の仮想マシンが乗っ取られた場合であっても、それ以外の仮想マシンの監視部から特定の仮想マシンの異常を検知できる効果がある。
　また、前記監視装置は、セキュアアプリと、ホストオペレーティングシステムと、１以上の仮想ソフトウェア基盤および１以上の仮想マシン上、または、１以上のコンテナ仮想化基盤および２以上のコンテナ上にて動作し、前記第一の実行権限と、前記第二の実行権限と、前記第三の実行権限と、前記第四の実行権限は、セキュアアプリの実行権限と、ホストオペレーティングシステムの実行権限と、仮想ソフトウェア基盤の実行権限と、仮想マシンのカーネル実行権限と、仮想マシンのユーザ実行権限と、コンテナの実行権限のうちの一つであり、同一の実行権限にて動作する仮想マシンの監視部が２以上存在する場合、第一の仮想マシンの監視部は、第二の仮想マシンの監視部のソフトウェアを監視対象に含み、前記第一の仮想マシンと前記第二の仮想マシンは、攻撃者によって改ざんされる可能性に応じて分類され、同一の実行権限にて動作するコンテナの監視部が２以上存在する場合、第一のコンテナの監視部は、第二のコンテナの監視部のソフトウェアを監視対象に含み、前記第一のコンテナと前記第二のコンテナは、攻撃者によって改ざんされる可能性に応じて分類される、監視装置である。
　これにより、ホストとなるオペレーティングシステムが、仮想化ソフトウェア基盤であるハイパーバイザを用いて、複数の仮想マシンを実行および管理する場合や、ＤｏｃｋｅｒやＫｕｂｅｒｎｅｔｅｓなどに代表されるコンテナ仮想化基盤を用いて複数のコンテナを実行および管理する場合であっても、外部ネットワークとの接続機能の有無など改ざんされる可能性に応じて仮想マシンまたはコンテナの信頼度は異なると想定できるため、複数の監視部を監視の信頼チェーンを構築することで、信頼度の低い第二の仮想マシンまたは第二のコンテナの監視部が乗っ取られた場合であっても、信頼度の高い第一の仮想マシンの監視部または第一のコンテナの監視部から異常を検知できる効果がある。
　また、前記監視部は、所定の時間経過と、所定の外部ネットワーク接続時間経過と、システム起動と、システム再起動と、外部ネットワーク接続確立と、外部デバイス接続のうち少なくとも１つを含むイベントに応じて、前記監視対象を監視する、監視装置である。
　これにより、システム起動時にソフトウェアの完全性を検証するセキュアブートのように前段の監視部によって完全性が検証された監視部が、後段の監視部を検証するといった直列的な監視方法ではなく、非同期でソフトウェアの改ざんリスクが高いイベントに応じて監視を実施することで、監視処理の割り込み時間を短縮できる効果がある。さらに、仮想マシンごとのＣＰＵの空き時間を活用して監視処理を行うなど、システムに負荷をかけることなく柔軟に監視処理の負担を配分できる効果がある。
　また、前記監視装置は、車載システム上において動作し、前記監視部は、所定の走行時間経過と、所定の停止時間経過と、所定の走行距離経過と、走行モードの切り替えと、給油または給電の終了と、車両診断の実施と、緊急アラートの発呼のうち少なくとも１つを含むイベントに応じて、前記監視対象を監視する、監視装置である。
　これにより、車載システムにおいて、ソフトウェアの改ざんリスクが高いイベントが発生するごとに、監視対象を監視することで、効率的に非同期監視を実施できる効果がある。
　また、前記監視部は、他の監視部の監視処理の実行回数、監視処理において異常と判定された回数と、監視処理において正常と判定された回数のうち少なくとも１つの回数に応じて、前記監視対象を監視する。
　これにより、例えば、第一の監視部の監視対象である第二の監視部がすべての監視対象の数だけ監視処理を実行した後に、第一の監視部が第二の監視部のソフトウェアの監視処理を実施することで、第二の監視部の監視結果をすべて信頼するための監視処理の回数を１回に削減できる効果がある。また、例えば、第一の監視部の監視対象である第二の監視部が異常を１回検知した場合に、第一の監視部が第二の監視部のソフトウェアの監視処理を実行することで、第二の監視部の監視対象に異常が発生した場合にのみ監視処理を実行でき、監視処理の回数を削減できる効果がある。また、例えば、第一の監視部の監視対象である第二の監視部が正常を５回検出した場合に、第一の監視部が第二の監視部のソフトウェアの監視処理を１回実行することで、第一の監視部の監視処理を少なくでき、監視処理の回数を削減できる効果がある。これは、強い実行権限のソフトウェアを動作させるためには実行モードの切り替えが必要である場合が想定できるため、実行モードの切り替え回数を削減することでのオーバーヘッドを削減できる効果がある。
　また、前記監視部は、前記監視対象がソフトウェアである場合、メモリまたはストレージに記憶されている前記監視対象であるソフトウェアのハッシュ値、マスク値、複製値のうち少なくとも１つの情報を取得値として取得し、事前に定義された期待値と取得値を比較し、一致する場合に正常と判定し、一致しない場合に異常と判定する、監視装置である。
　これにより、ソフトウェアの改ざんが行われた場合は、期待値と取得値が異なるため、ソフトウェア改ざんの有無を判定できる効果がある。また、ハッシュ値を用いることで、複製値よりも効率的に改ざんを判定でき、マスク値を用いることで複製値よりも効率的に改ざんの有無を判定できる効果がある。また、複製値を用いることで、ハッシュ値よりも正確に改ざんを判定でき、マスク値を用いることで、ハッシュ値よりも正確に改ざんを判定できる効果がある。
　また、前記ソフトウェアは仮想ソフトウェア基盤のプログラムと設定ファイル、仮想マシンのカーネルプログラムと設定ファイル、仮想マシン上のユーザアプリのプログラムと設定ファイル、前記監視部のプログラムと設定ファイルのうち少なくとも１つを含む、監視装置である。
　これにより、ハイパーバイザと仮想マシンとユーザアプリと監視部に関連するソフトウェアの改ざんの有無を判定できる。
　また、前記監視部は、前記監視対象が通信ログである場合、通信ログを取得し、許可リストと、拒否リストと、正常時の統計情報のうち少なくとも１つを用いて通信ログを検証し、前記許可リストに含まれる場合に正常と判定し、含まれない場合に異常と判定し、前記拒否リストに含まれない場合に正常と判定し、含まれる場合に正常と判定し、前記正常時の統計情報から逸脱していない場合に正常と判定し、逸脱している場合に正常と判定する、監視装置である。
　これにより、異常な通信が送受信された場合は許可リストに含まれず、拒否リストに含まれ、正常時の統計情報から逸脱するため、通信の異常を判定できる。さらに、異常な通信の送信元や宛先情報を取得でき、送信元のソフトウェアが改ざんされている可能性が高く、宛先のソフトウェアが次の攻撃の対象になっている可能性が高いと把握できる効果がある。
　また、前記通信ログは、イーサネット（登録商標）と、ＣＡＮ（登録商標）プロトコルと、ＦｌｅｘＲａｙ（登録商標）プロトコルと、ＳＯＭＥ／ＩＰプロトコルと、ＳＯＭＥ／ＩＰ－ＳＤプロトコルと、システムコールと、ハイパーコールのうち少なくとも一つを含む、監視装置である。
　これにより、車載システムに搭載されるネットワークプロトコルを監視対象とすることで、プロトコル特有のパラメータを用いて通信の異常を判定できる効果がある。さらに、異常と判定された通信ログから送信元と宛先を取得でき、異常が発生しうる監視部や監視対象を特定できる効果がある。さらに、特権命令であるシステムコールや、ハイパーコールを監視対象とすることで、実行権限の境界にて発生する異常を判定でき、異常が発生しうる監視部や監視対象を特定できる効果がある。
　また、前記監視部は、前記監視対象ごとに設定された優先度に応じて、前記監視対象の監視頻度と、監視精度と、監視手段のうち少なくとも１つを変更する、監視装置である。
　これにより、監視対象ごとに改ざんされる可能性と改ざんされた場合の影響の大きさには差があると想定できるため、監視対象ごとに適切な優先度を設定することで、限られたリスース内で改ざんリスクの高い監視対象を重点的に監視できる効果がある。
　また、前記優先度は、前記監視対象の実行権限と、前記監視部または前記監視が動作する仮想マシンが外部ネットワーク接続機能を有するか否かと、前記監視部または前記監視が動作する仮想マシンが車両制御機能を有するか否かのうち少なくとも１つに応じて設定される、監視装置である。
　これにより、強い実行権限で動作するソフトウェアは脆弱性を含まないように単純なアルゴリズムで実装されると想定できるため、改ざんされる可能性が低いため優先度を低く設定できる効果がある。また、外部ネットワークと接続されない仮想マシンや、信頼可能な車両の制御機能をもつ仮想マシンは改ざんされる可能性が低いため、優先度を低く設定できる効果がある。
　また、前記監視装置は、さらに、前記監視装置が動作するシステムの状態またはイベントに応じて、前記監視情報に含まれる優先度と、前記監視対象に含まれる監視担当と監視対象の組み合わせである監視構成のうち少なくとも１つを変更する管理部を含む、監視装置である。
　これにより、システムの状態またはイベントによって監視対象の重要度に差がある場合、監視情報を適切な固定値として設定することは困難であると想定できるため、システム起動後であっても監視情報と監視構成を柔軟に変更することで、効果的に監視できる効果がある。例えば、優先度を柔軟に変更すし、優先度に応じて監視対象の監視頻度と監視精度と監視手段を変更することで、限られたリスース内で改ざんリスクの高い監視対象を重点的に監視できる効果がある。また、一つの仮想マシンが再起動するなど、一部の監視部が動作できない状態になった場合に他の監視部が動作できない監視対象の監視を引き継ぐように監視情報を変更することで、監視対象を継続的に監視できる効果がある。また、例えば、一つの仮想マシンが異常と判定された場合に他の監視部が監視対象の監視を引き継ぐことで、監視対象を信頼できる監視部から監視できる効果がある。また、例えば、一つの仮想マシンが異常と判定された場合に他の監視部が監視対象の監視を追加で実施することで、複数の監視部によって監視を強化できる効果がある。また、例えば、一つの仮想マシンのＣＰＵやメモリのリソースが圧迫している場合、他の監視部が監視対象の監視を引き継ぐことで、リソースが圧迫によるシステム影響を低減できる効果がある。
　また、前記管理部は、外部ネットワーク接続中か否かと、外部ネットワーク接続確立イベントの発生と、監視マシンのシステム状態と、前記監視部の監視結果と、異常を検知した監視部の実行権限と、異常を検知したソフトウェアの実行権限と、異常を検知した通信ログの宛先または送信元のうち少なくとも１つに応じて、前記優先度を変更する、監視装置である。
　これにより、ネットワーク接続に関する状態は攻撃可能性に影響するため、監視対象の攻撃可能性の変化に応じて優先度を変更できる効果がある。さらに、ソフトウェアの異常が判定された場合、異常ソフトウェアと同じ仮想マシンのソフトウェアや、同じ実行権限で動作するソフトウェアや、異常を判定した監視部のソフトウェアにおいて、攻撃が発生する可能性が高いと想定できるため、攻撃可能性の変化に応じて優先度を変更できる効果がある。さらに、通信の異常を判定した場合、通信の送信元に異常が発生している可能性が高く、通信の送信先に攻撃が発展する可能性が高いため、攻撃可能性の変化に応じて優先度を変更できる効果がある。
　また、前記監視装置は、車載システム上において動作し、前記管理部は、車両の走行状態に応じて、車両の制御機能を有する仮想マシンで動作する監視対象の優先度を変更し、車両の走行状態は、停止中、手動運転中、高度運転支援中、自動運転中のうちいずれかである、監視装置である。
　これにより、自動運転中や高度運転支援中の場合、車両の制御機能を有する制御仮想マシンのソフトウェアから、車両の走る、曲がる、止まるに関わる制御コマンドが送信され、エンジン、ステアリング、ブレーキなど制御する制御ＥＣＵが制御コマンドに従うと想定でき、ソフトウェア改ざんの影響が大きいため、車両の制御機能を有する制御仮想マシンのソフトウェアの優先度を上げて重点的に監視できる効果がある。一方で、停止中または手動走行中の場合、制御ＥＣＵが制御コマンドに従わない状態であると想定でき、ソフトウェア改ざんの影響が小さいため、車両の制御機能を有する制御仮想マシンのソフトウェアの監視の優先度を下げることで、他の監視対象の監視処理を優先できる効果がある。
　また、前記管理部は、監視構成の変更後であっても、信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、監視構成を変更する、監視装置である。
　これにより、監視構成を変更したとしても、強い実行権限の監視部から弱い実行権限の監視部のソフトウェアを監視することができ、改ざんされる可能性が低い仮想マシンの監視部から改ざんされる可能性の高い仮想マシンの監視部のソフトウェアを監視できるため、いずれかの弱い実行権限監視部が乗っ取られた場合であっても、異常を判定できる効果がある。
　また、前記管理部は、外部ネットワーク接続中か否かと、外部ネットワーク接続確立イベントの発生と、仮想マシンのシステム状態と、前記監視部の監視結果と、異常を検知した監視部の実行権限と、異常を検知したソフトウェアの実行権限と、異常を検知した通信ログの宛先または送信元のうち少なくとも１つに応じて、監視構成を変更する、監視装置である。
　これにより、ネットワーク接続に関する状態は攻撃可能性に影響するため、監視対象の攻撃可能性の変化に応じて監視構成を変更できる効果がある。また、一つの仮想マシンが再起動するなど、一部の監視部が無効化状態になった場合に他の監視部が監視対象の監視を引き継ぐことで、監視対象を継続的に監視できる効果がある。さらに、一つの仮想マシンが異常と判定された場合に他の監視部が監視対象の監視を引き継ぐことで、監視対象を信頼できる監視部から監視できる効果がある。さらに、一つの仮想マシンが異常と判定された場合に他の監視部が監視対象の監視を追加で実施することで、複数の監視部によって監視を強化できる効果がある。さらに、一つの仮想マシンのＣＰＵやメモリのリソースが圧迫している場合、他の監視部が監視対象の監視を引き継ぐことで、リソースが圧迫によるシステム影響を削減できる効果がある。
　また、前記監視装置は、車載システム上において動作し、前記管理部は、車両の走行状態に応じて、車両の制御機能を有する仮想マシンに関係する監視構成を変更し、車両の走行状態は、停止中、手動運転中、高度運転支援中、自動運転中のうちいずれかである、監視装置である。
　これにより、自動運転中や高度運転支援中の場合、車両の制御機能を有する制御仮想マシンのソフトウェアから、車両の走る、曲がる、止まるに関わる制御コマンドが送信され、エンジン、ステアリング、ブレーキなど制御する制御ＥＣＵが制御コマンドに従うと想定でき、ソフトウェア改ざんの影響が大きいため、複数の監視部によって制御仮想マシンのソフトウェアを監視するよう監視構成を変更できる効果がある。停止中または手動走行中の場合、制御ＥＣＵが制御コマンドに従わない状態であると想定でき、ソフトウェア改ざんの影響が小さいため、一つのみの監視部によって負荷の小さい通常の監視を実施できる効果がある。
　また、前記管理部は、予め定義された２以上の監視構成から一つを選択する手段と、監視部を頂点とし、監視担当を道の始点とし、監視対象を道の終点とする有向グラフとして前記監視構成を記憶し、所定のアルゴリズムで有向グラフを再構築する手段と、監視部をノードとし、監視担当を親ノードとし、監視対象を子ノードとするツリー構造として前記監視構成を記憶し、所定のアルゴリズムでツリー構造を再構築する手段のうち少なくとも１つの手段で監視構成を変更する、監視装置である。
　これにより、複数の監視構成のパターンから、現在のシステム状況およびイベントに応じて適切な監視構成に変更できる効果がある。また、監視構成を有向グラフのデータ構造で保持することで、一部の監視部が無効化または一部の監視部において異常が判定されたなどの場合に、少なくとも１つの監視部が監視対象を監視できるよう監視構成を再計算可能にする効果がある。また、前記管理部は、監視部をノードとし、監視担当を親ノードとし、監視対象を子ノードとするツリー構造として前記監視構成を記憶し、所定のアルゴリズムでツリー構造を再構築することで、前記監視構成を変更する、監視装置である。また、監視構成をツリー構造のデータ構造で保持することで、一部の監視部が無効化または一部の監視部において異常が判定されたなどの場合に、少なくとも１つの監視部が監視対象を監視できるよう監視構成を再計算可能にする効果がある。
　また、前記監視装置は、さらに、監視サーバーへ監視結果を通知する監視サーバー通知部を備える、監視装置である。
　これにより、監視サーバーを介して監視結果をセキュリティ分析官へ通知でき、異常が発生した場合にはソフトウェアの更新など対策を検討できる効果がある。
　また、監視装置と監視サーバーで構成される監視システムであって、前記監視装置は、ソフトウェアまたは通信ログを監視対象として監視する２以上の監視部と、監視部識別子と、監視対象識別子と、正常判定時刻と、異常判定時刻と、のうち少なくとも２つを監視結果として前記監視サーバーへ送信する監視サーバー通信部と、を備え、前記監視サーバーは、前記監視結果を受信し、グラフィカルユーザーインターフェース上に前記監視結果を表示する監視結果表示部を備える、監視システムである。
　これにより、セキュリティ分析官は監視結果を視覚的に把握することができ、異常が発生した場合にはソフトウェアの更新など対策を迅速に検討できる効果がある。
　また、前記監視結果表示部は、システムアーキテクチャに関連付けて前記監視結果を表示し、異常を検知した監視部または異常が検知された監視対象を強調する手段と、所定のタイムラインに関連付けて監視結果を表示し、正常判定時刻または異常判定時刻を強調する手段のうち少なくとも１つの手段でグラフィカルユーザーインターフェース上に監視結果を表示する、監視システムである。
　これにより、セキュリティ分析官は監視部の場所と、監視対象の場所、監視結果を直感的に把握することができ、異常が発生した場合にはソフトウェアの更新など対策をより迅速に検討できる効果がある。また、セキュリティ分析官は監視結果の時系列を直感的に把握することができ、異常が発生した場合にはソフトウェアの更新など対策をより迅速に検討できる効果がある。
　また、前記監視サーバーは、さらに、前記監視対象と、前記監視対象を監視する監視部と、前記監視対象の優先度と、前記優先度に対応した監視方法のうち少なくとも１つの監視情報の変更を受け付け、前記監視装置に前記変更を要求する監視情報変更部を備え前記監視装置は、前記監視情報変更部の要求に応じて前記監視情報を更新する監視情報更新部を備える、監視システムである。
　これにより、セキュリティ分析官は監視結果を分析した結果、監視対象や監視部、優先度、優先度ごとの監視方法などの修正が必要であると判断した場合に、迅速にシステムに修正を反映することができる効果がある。
　また、ソフトウェアと通信ログのうち少なくとも１つを監視対象として監視する２以上の監視ステップであって、前記監視ステップは、それぞれ２種類の実行権限のうちいずれか一つの実行権限にて実行され、信頼度の低い監視ステップを実行するソフトウェアを少なくとも１つの信頼度の高い監視ステップにて監視できるように、第一の実行権限にて実行される第一の監視ステップは第二の実行権限にて実行される第二の監視ステップを実行するソフトウェアを監視対象に含む、監視方法である。
　これにより、システムに侵入した攻撃者は弱い実行権限の獲得後、より強い実行権限の獲得を目指すと想定できるため、第一の実行権限よりも弱い第二の実行権限が乗っ取られた後、第二の監視部のソフトウェアを改ざんすることで監視を回避しようと試みた場合であっても、第一の監視部から、第二の監視部のソフトウェアの異常を検知できる効果がある。また、強い実行権限でプログラムを動作させる環境とは弱い実行権限でプログラムを動作させる環境は分離されると想定できるため、実行権限が異なる２段階の監視部を用いることによって、２種類の環境に渡って広い範囲の監視対象を監視できる効果がある。また、強い実行権限で動作するソフトウェアは脆弱性を含まないように単純なアルゴリズムで実装されると想定できるため、強い実行権限で動作する監視部には単純なアルゴリズムを採用し、弱い実行権限で動作する監視部には高度で複雑なアルゴリズムを採用できる効果がある。
　なお、これらの全般的又は具体的な態様は、システム、方法、集積回路、コンピュータプログラム又はコンピュータで読み取り可能なＣＤ－ＲＯＭ等の記録媒体で実現されても良く、システム、方法、集積回路、コンピュータプログラム又は記録媒体の任意な組み合わせで実現されてもよい。
　以下、実施の形態に係る監視装置について図面を参照しながら説明する。ここで示す実施の形態は、いずれも本開示の一具体例を示すものである。従って、以下の実施の形態で示される数値、構成要素、構成要素の配置及び接続形態、並びに、処理の要素としてのステップ及びステップの順序等は、一例であって本開示を限定するものではない。以下の実施の形態における構成要素のうち、独立請求項に記載されていない構成要素については、任意に付加可能な構成要素である。また、各図は、模式図であり、必ずしも厳密に図示されたものではない。
　（実施の形態１）
　［監視システムの全体構成図］
　図１は、本開示の実施の形態１における監視システムの全体構成図である。
　監視システムは、監視サーバー１０と車載システム２０から構成され、外部ネットワーク３０を介して監視サーバー１０と車載システム２０が接続される。
　外部ネットワーク３０は、例えば、インターネットである。外部ネットワーク３０の通信方法は、有線であっても無線であってもよい。また、無線通信方式は既存技術であるＷｉ－Ｆｉ（登録商標）や、３Ｇ／ＬＴＥ（Ｌｏｎｇ　Ｔｅｒｍ　Ｅｖｏｌｕｔｉｏｎ）やＢｌｕｅｔｏｏｔｈ、Ｖ２Ｘ通信方式であってもよい。
　監視サーバー１０は、車載システム２０から車載システム２０のセキュリティ状態に関する情報である監視結果を取得して、グラフィカルユーザーインターフェースを用いて監視結果を表示する装置である。監視サーバー１０は、例えば、セキュリティオペレーションセンターにて、セキュリティ分析官が監視結果を確認して、車載システム２０において異常が発生した場合にソフトウェア更新などの対策を検討する際に利用される。
　車載システム２０は、通信の制御と、車両の制御と、映像の出力などを実施し、車載システム２０のセキュリティ状態を監視し、監視サーバー１０へセキュリティ状態の監視結果を通知する装置である。図１では、車載システム２０は１台のみ記載しているが、１以上の車載システム２０それぞれが、監視サーバー１０へセキュリティ状態の監視結果を送信する。車載システム２０の詳細は後述する。
　［車載システム２０の全体構成図］
　図２は、本開示の実施の形態における車載システムの構成図を示す図である。
　車載システム２０は、統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂと、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂを備える。
　統合ＥＣＵ２００と、ゲートウェイＥＣＵ３００は、ネットワークプロトコルの一種のＣＡＮ（Ｃｏｎｔｒｏｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）であるＣＡＮ４０を介して接続される。ここで、ＣＡＮでなくとも、ＣＡＮ－ＦＤや、ＦｌｅｘＲａｙプロトコルなどの車載システムで利用されるネットワークプロトコルであってもよい。
　また、ゲートウェイＥＣＵ３００と、ステアリングＥＣＵ４００ａと、ブレーキＥＣＵ４００ｂは、ＣＡＮ４１を介して接続される。
　また、統合ＥＣＵ２００と、ＺｏｎｅＥＣＵ５００は、ネットワークプロトコルの一種のＥｔｈｅｒｎｅｔ（商標登録）のプロトコルであるイーサネット５０を介して接続される。イーサネット５０は、例えば、イーサネット５０はＳＯＭＥ／ＩＰ（Ｓｃａｌａｂｌｅ　Ｓｅｒｖｉｃｅ－Ｏｒｉｅｎｔｅｄ　ＭｉｄｄｌｅｗａｒＥ　ｏｖｅｒ　ＩＰ）プロトコルである。ここで、ＳＯＭＥ／ＩＰでなくとも、ＳＯＭＥ／ＩＰ－ＳＤや、ＣＡＮ－ＸＬなど車載システムで利用されるネットワークプロトコルであってもよい。
　また、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂは、イーサネット５０を介して接続される。
　また、ＺｏｎｅＥＣＵ５００と、フロントカメラＥＣＵ６００ａと、リアカメラＥＣＵ６００ｂは、イーサネット５１を介して接続される。
　また、統合ＥＣＵ２００と、監視サーバー１０は、外部ネットワーク３０を介して接続される。
　統合ＥＣＵ２００は、外部ネットワーク３０とＣＡＮ４０とイーサネット５０を介してメッセージを送受信する通信制御と、ＣＡＮ４０とイーサネット５０を介してゲートウェイＥＣＵ３００およびＺｏｎｅＥＣＵ５００へ車両の制御を指示する車両制御と、インフォテイメントシステムやインストルメントパネルへの映像出力を実施し、統合ＥＣＵ２００のセキュリティ状態を監視し、監視サーバー１０へ監視結果を通知するＥＣＵである。統合ＥＣＵ２００の詳細は後述する。
　ゲートウェイＥＣＵ３００は、統合ＥＣＵ２００と、ステアリングＥＣＵ４００ａおよびブレーキＥＣＵ４００ｂの間で送受信されるメッセージを仲介するＥＣＵである。
　ステアリングＥＣＵ４００ａは、車両に搭載されるステアリングの操舵を制御するＥＣＵである。
　ブレーキＥＣＵ４００ｂは、車両に搭載されるブレーキを制御するＥＣＵである。
　図２では、ステアリングＥＣＵ４００ａとブレーキＥＣＵ４００ｂのみを記載しているが、車両のエンジンやボディを制御するＥＣＵを用いて車両の走る、曲がる、止まるといった制御を実現する。
　ＺｏｎｅＥＣＵ５００は、統合ＥＣＵ２００と、フロントカメラＥＣＵ６００ａおよびリアカメラＥＣＵ６００ｂの間で送受信されるメッセージを仲介するＥＣＵである。
　フロントカメラＥＣＵ６００ａは、車両の前方に搭載されたカメラの映像を取得するＥＣＵである。
　リアカメラＥＣＵ６００ｂは、車両の後方に搭載されたカメラの映像を取得するＥＣＵである。
　図２では、フロントカメラＥＣＵとリアカメラＥＣＵのみを記載しているが、ＧＰＳなどの各種センサー情報を収集するＥＣＵを用いて、自動運転やアダプティブクルーズコントロール、自動駐車などの先進運転支援機能を実現する。
　［統合ＥＣＵの構成図］
　図３は、本開示の実施の形態１における統合ＥＣＵ２００の構成図である。統合ＥＣＵ２００は、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００（以下、外部アプリＡ１００と、制御アプリＡ２００と、映像アプリＡ３００を総称してアプリケーションと呼ぶことがある）と、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００（以下、外部仮想マシンＶＭ１００と、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００を総称して仮想マシンと呼ぶことがある）と、ハイパーバイザＨＶ１００と、セキュアアプリＳＡ１００と、セキュアオペレーティングシステムＳＯＳ１００を備える。
　ハイパーバイザＨＶ１００はハイパーバイザ等の仮想ソフトウェア基盤であり、１以上の仮想マシンを実行および管理するソフトウェアである。一般に、ハイパーバイザはタイプ１と呼ばれるベアメタル型ハイパーバイザと、タイプ２と呼ばれるホスト型と区別される。組み込みシステムでは、一般に、ハイパーバイザによる処理のオーバーヘッドを考慮して、タイプ１が用いられる。タイプ１のハイパーバイザは、コードサイズが小さいため、脆弱性を含む可能性が低く、アプリケーションや仮想マシンと比較して信頼できると想定できる。
　本開示の実施の形態１では、タイプ１のハイパーバイザを例にあげて説明するが、タイプ２のハイパーバイザやコンテナ型の仮想化アプリケーションによる仮想化システムであってもよい。
　セキュアオペレーティングシステムＳＯＳ１００は、脆弱性を含まないように実装された信頼可能なオペレーティングシステムである。さらに、システム起動時に信頼可能なハードウェアのＲｏｏｔ　Ｏｆ　Ｔｒｕｓｔからオペレーティングシステムのソフトウェアは検証されるため、アプリケーション、仮想マシン、ハイパーバイザＨＶ１００の中で最も信頼できると想定できる。セキュアオペレーティングシステムは、例えば、ＴＥＥ（Ｔｒｕｓｔｅｄ　Ｅｘｅｃｕｔｉｏｎ　Ｅｎｖｉｒｏｎｍｅｎｔ）と呼ばれる実行環境の制御を用いて実現される。また、例えば、ＡＲＭ系のＣＰＵ（Ｃｅｎｔｒａｌ　Ｐｒｏｃｅｓｓｉｎｇ　Ｕｎｉｔ）におけるＣｏｒｔｅｘ－Ａファミリでは標準機能の１つであるＴｒｕｓｔＺｏｎｅ機構により実現され得る。また、ＡｐｐｌｅのＳＥＰ（Ｓｅｃｕｒｅ　Ｅｎｃｌａｖｅ　Ｐｒｏｃｅｓｓｏｒ）、または、ＧｏｏｇｌｅのＴｉｔａｎＭなどによっても実現される。
　セキュアアプリＳＡ１００は、脆弱性を含まないように実装された信頼可能なアプリケーションである。信頼できるセキュアオペレーティングシステムＳＯＳ１００の上で動作するため、アプリケーション、仮想マシン、ハイパーバイザＨＶ１００より信頼できると想定できる。一方で、脆弱性を含まない実装が求められるため、セキュアアプリＳＡ１００のプログラムは単純であることが要求される。
　外部アプリＡ１００は、外部ネットワーク３０を介して監視サーバー１０と通信するアプリケーションである。攻撃者の侵入口となりうる外部ネットワーク３０と接続されるため、外部ネットワーク３０と接続されていない制御アプリＡ２００と映像アプリＡ３００に比べて脆弱であると想定できる。
　外部仮想マシンＶＭ１００は、外部アプリＡ１００を動作させるオペレーティングシステムである。攻撃者の侵入口となりうる外部アプリＡ１００を動作させているため、制御仮想マシンＶＭ２００と、映像仮想マシンＶＭ３００に比べて脆弱であると想定できる。
　制御アプリＡ２００は、ＣＡＮ４０を介してゲートウェイＥＣＵ３００と通信し、車両を制御するアプリケーションである。外部ネットワーク３０と接続されていないため、外部アプリＡ１００に比べて信頼できると想定できる。さらに、車両の制御に関わるソフトウェア開発では、機能安全規格に適用するため、セキュアな設計および実装がなされるため、外部アプリＡ１００に比べて信頼できると想定できる。ただし、制御アプリＡ２００が乗っ取られた場合、車両の制御の機能を攻撃者が使えるため、安全性への影響が大きいと想定できる。
　制御仮想マシンＶＭ２００は、制御アプリＡ２００を動作させるオペレーティングシステムである。外部ネットワーク３０と接続されていないため、攻撃者の侵入口となりうる可能性は低いと想定できる。さらに、車両の制御に関わるソフトウェア開発では、機能安全規格に適用するため、セキュアな設計および実装がなされるため、外部アプリＡ１００や外部仮想マシンＶＭ１００に比べて信頼できると想定できる。ただし、制御仮想マシンＶＭ２００が乗っ取られた場合、車両の制御の機能を攻撃者が使えるため、外部仮想マシンＶＭ１００や映像仮想マシンＶＭ３００が乗っ取られた場合と比較して、影響が大きいと想定できる。
　映像アプリＡ３００は、イーサネット５０を介してＺｏｎｅＥＣＵ５００と通信し、カメラの映像などを取得し、インフォテイメントシステムやインストルメントパネル、ヘッドアップディスプレイに映像を出力するアプリケーションである。また、カメラ映像は自動運転などの先進運転支援機能を実現するための情報としても利用される。外部ネットワーク３０と接続されていないため、攻撃者の侵入口となる可能性が低く、外部アプリＡ１００に比べて信頼できると想定できる。また、映像アプリＡ３００が乗っ取られた場合、車両の制御の機能を攻撃者は使えないため、制御仮想マシンＶＭ２００が乗っ取られた場合と比較して、安全性への影響が小さいと想定できる。
　映像仮想マシンＶＭ３００は、映像アプリＡ３００を動作させるオペレーティングシステムである。外部ネットワーク３０と接続されていないため、攻撃者の侵入口となる可能性が低く、外部アプリＡ１００に比べて信頼できると想定できる。また、映像アプリＡ３００が乗っ取られた場合、車両の制御の機能を攻撃者は使えないため、制御仮想マシンＶＭ２００が乗っ取られた場合と比較して、安全性への影響が小さいと想定できる。
　ここで、各プログラムの実行権限について説明する。一般に、ＣＰＵは複数の特権レベルを各プログラムに割り当てることができる。例えば、ＡＲＭ系のＣＰＵでは、ＥＬ（Ｅｘｅｐｔｉｏｎ　Ｌｅｖｅｌ）に対応し、Ｉｎｔｅｌ系のＣＰＵでは、Ｐｒｏｔｅｃｔｉｏｎ　Ｒｉｎｇに対応する。さらに、ＴＥＥを用いてセキュアワールドとノーマルワールドの２種類の実行環境の制御することで、セキュアにプログラムを実行することができる。一般に、この特権レベルと２種類の実行環境の制御によって、５種類の実行権限を使い分けることができる。本開示の実施の形態１においては、セキュアオペレーティングシステムに、最も強いセキュアな実行権限（ＰＬ４）を割り当て、オペレーティングシステム上のアプリケーションに次に強いセキュアな実行権限（ＰＬ３）を割り当て、ハイパーバイザＨＶ１００に次に強い実行権限（ＰＬ２）を割り当て、仮想マシンに次に強い実行権限（ＰＬ１）を割り当て、仮想マシン上のアプリケーション（ＰＬ０）に最も弱い実行権限を割り当てる。また、弱い実行権限で動作するプログラムからは、強い実行権限で動作するソフトウェアを改ざんすることは基本的には困難である。しかし、実行権限が強い場合であっても、脆弱性や設計不備によってソフトウェアを改ざんされる可能性があるため、強い実行権限で動作するソフトウェアはシンプルなプログラムであること要求される。
　上述した通り、外部アプリＡ１００が改ざんされる可能性が最も高いため信頼度が低く、制御アプリＡ２００、映像アプリＡ３００、外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００、映像仮想マシンＶＭ３００、ハイパーバイザＨＶ１００、セキュアアプリＳＡ１００、セキュアオペレーティングシステムＳＯＳ１００の順番に、改ざんされる可能性が低くなる。改ざんされる可能性が低いことは信頼度が高いことを意味する。
　ここで、攻撃者の攻撃シナリオについて説明する。攻撃者は、外部アプリＡ１００の脆弱性を悪用して、外部ネットワーク３０から外部仮想マシンＶＭ１００へ侵入し、ユーザ権限を獲得する。そして、外部仮想マシンＶＭ１００のシステムコール等の脆弱性を突いて、外部仮想マシンＶＭ１００のカーネル権限を獲得する。そして、ハイパーバイザＨＶ１００のハイパーコール等の脆弱性を突いて、ハイパーバイザＨＶ１００の権限または制御仮想マシンＶＭ２００や映像仮想マシンＶＭ３００の権限を獲得する。ここで、ハイパーコールとは、例えば、仮想マシン間の内部通信と、仮想マシンの起動や終了を指示する特権命令である。
　上述した攻撃シナリオにおいて、攻撃者の振る舞いを正確に捕捉するために、アプリケーション、仮想マシン、ハイパーバイザＨＶ１００、セキュアアプリＳＡ１００それぞれにセキュリティ対策機構を導入すると想定できる。セキュリティ対策機構は後述するアプリケーション監視部、仮想マシン監視部、ＨＶ監視部ＨＶ１１０、ＳＡ監視部ＳＡ１１０を含む。
　図３では記載を省略しているが、燃料や給電状態、給油状態を管理する機能や、事故などシステム異常が発生した場合に緊急アラートを発呼する機能、車両診断を制御する機能、外部デバイス接続を監視する機能が統合ＥＣＵ２００に搭載される。
　［統合ＥＣＵの構成図の詳細］
　図４は、本開示の実施の形態１における統合ＥＣＵの構成図の詳細を示す図である。
　外部アプリＡ１００は外部通信とアプリ領域のソフトウェアを監視するアプリ監視部Ａ１１０を備え、制御アプリＡ２００はＣＡＮ通信とアプリ領域のソフトウェアを監視するアプリ監視部Ａ２１０を備え、映像アプリＡ３００はイーサネット通信とアプリ領域のソフトウェアを監視するアプリ監視部Ａ３１０を備える（以下、アプリ監視部Ａ２１０と、アプリ監視部Ａ２１０と、アプリ監視部Ａ２１０を総称してアプリケーション監視部と呼ぶことがある）。また、外部仮想マシンＶＭ１００はシステムコールとハイパーコールとＶＭ領域（ＯＳ領域またはカーネル領域とも呼ぶ）のソフトウェアとアプリ領域のソフトウェアを監視するＶＭ監視部ＶＭ１１０を備え、制御仮想マシンＶＭ２００はシステムコールとハイパーコールとＶＭ領域（ＯＳ領域またはカーネル領域とも呼ぶ）のソフトウェアとアプリ領域のソフトウェアを監視するＶＭ監視部ＶＭ２１０を備えと、映像仮想マシンＶＭ３００はシステムコールとハイパーコールとＶＭ領域（ＯＳ領域またはカーネル領域とも呼ぶ）のソフトウェアとアプリ領域のソフトウェアを監視するＶＭ監視部ＶＭ３１０を備える（以下、ＶＭ監視部ＶＭ１１０と、ＶＭ監視部ＶＭ２１０と、ＶＭ監視部ＶＭ３１０を総称して仮想マシン監視部と呼ぶことがある）。また、ハイパーバイザＨＶ１００はＨＶ領域のソフトウェアとＶＭ領域のソフトウェアを監視するＨＶ監視部ＨＶ１１０を備える。また、セキュアアプリＳＡ１００はＨＶ領域のソフトウェアとＶＭ領域のソフトウェアを監視するＳＡ監視部ＳＡ１１０と、監視情報を管理する管理部ＳＡ１２０を備える（以下、アプリケーション監視部と、仮想マシン監視部と、ＨＶ監視部ＨＶ１１０と、ＳＡ監視部ＳＡ１１０を総称して多層監視部と呼ぶことがある）。監視情報の詳細は後述する。アプリケーションと、アプリケーション監視部と、仮想マシンと、仮想マシン監視部と、ハイパーバイザＨＶ１００と、ＨＶ監視部ＨＶ１１０と、セキュアアプリＳＡ１００と、ＳＡ監視部ＳＡ１１０の詳細は後述する。
　このように、攻撃者の振る舞いを正確に捕捉するために、アプリケーション、仮想マシン、ハイパーバイザＨＶ１００、セキュアアプリＳＡ１００それぞれにセキュリティ対策機構であるアプリケーション監視部と、仮想マシン監視部と、ＨＶ監視部ＨＶ１１０と、ＳＡ監視部ＳＡ１１０を導入すると想定できる。しかし、攻撃者は獲得した実行権限において実行されるセキュリティ対策機構のソフトウェアを改ざんすることで、セキュリティ対策機構を無効化できるため、単純にセキュリティ対策機構を導入するだけでは不十分である。
　また、セキュリティ対策機構を改ざんされる可能性が低いセキュアアプリＳＡ１００やセキュアオペレーティングシステムＳＯＳ１００にすべてのセキュリティ対策機構を実装することが想定できるが、上述の通り、脆弱性が含まれないシンプルなプログラムが要求されるため、複雑なアルゴリズムがセキュリティ対策機構に必要とされる場合、実装は困難である。例えば、ネットワークの異常検知に利用される通信ログの蓄積処理や統計処理、機械学習による処理は、セキュアアプリＳＡ１００やセキュアオペレーティングシステムＳＯＳ１００では実施できない場合がある。また、実行環境の分離によって、セキュアアプリＳＡ１００やセキュアオペレーティングシステムＳＯＳ１００がアクセス可能なストレージ領域とメモリ領域は限定されるため、セキュリティ対策機構に必要な対象を取得できない場合、実装は困難である。例えば、セキュアアプリＳＡ１００やセキュアオペレーティングシステムＳＯＳ１００からは、アプリケーションのソフトウェアや、アプリケーションが利用する通信を取得できない場合がある。
　上記２つの理由から、アプリケーション、仮想マシン、ハイパーバイザＨＶ１００、セキュアアプリＳＡ１００それぞれにセキュリティ対策機構を導入することが望ましいが、セキュリティ対策機構自体が改ざんされるリスクが課題となる。そこで、例えば、ＳＡ監視部ＳＡ１１０がＨＶ監視部ＨＶ１１０のソフトウェアを監視し、ＨＶ監視部ＨＶ１１０が仮想マシン監視部のソフトウェアを監視し、仮想マシン監視部がアプリケーション監視部のソフトウェアを監視することで、アプリケーション監視部が改ざんされた場合であっても仮想マシン監視部が異常を検知でき、仮想マシン監視部のソフトウェアが改ざんされた場合であってもＨＶ監視部ＨＶ１１０が異常を検知でき、ＨＶ監視部ＨＶ１１０のソフトウェアが改ざんされた場合であってもＳＡ監視部ＳＡ１１０が異常を検知できる。このように、それぞれの監視部を、より強い実行権限またはより高い信頼度で動作する少なくとも１つの多層監視部から監視することで、一つの監視部が改ざんされて無効化された場合であっても他の監視部から異常を検知できる。そして、信頼可能なソフトウェアであるＳＡ監視部ＳＡ１１０から、ハイパーバイザＨＶ１００、仮想マシン、アプリケーションまで監視を連鎖させるため、攻撃者はすべての監視を回避することは困難である。上記のように、多層監視部において、より強い実行権限またはより高い信頼度を有する監視部から、弱い実行権限または低い信頼度を有する監視部を監視する連鎖を構築することを監視の信頼チェーンを構築すると呼ぶ。
　［外部アプリの構成図］
　図５は、本開示の実施の形態１における外部アプリの構成図を示す図である。
　外部アプリＡ１００は、外部ネットワーク３０を介して通信する外部通信部Ａ１０１と、外部通信とシステムコールを用いて、ナビゲーション情報の取得と音楽やビデオなどのストリーミング情報の取得、更新ソフトウェアのダウンロードを実施する外部アプリ実行部Ａ１０２と、外部アプリのプログラムと設定ファイルを記憶するストレージおよびメモリであるアプリ領域記憶部Ａ１０３と、アプリ監視部Ａ１１０を備える。
　アプリ監視部Ａ１１０は、監視対象取得部Ａ１１１と、システム状態取得部Ａ１１２と、監視部Ａ１１３と、監視情報記憶部Ａ１１４と、監視情報更新部Ａ１１５と、監視結果通知部Ａ１１６を備える。
　監視対象取得部Ａ１１１は、アプリ領域記憶部Ａ１０３から監視対象であるソフトウェアに関する情報を取得し、外部通信部Ａ１０１から外部通信ログに関する情報を取得する機能を有する。
　システム状態取得部Ａ１１２は、外部通信部Ａ１０１からインターネット接続状態と、監視部Ａ１１３からセキュリティ状態を、システム状態として取得する機能を有する。
　監視部Ａ１１３は、監視対象取得部Ａ１１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部Ａ１１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。さらに、監視対象取得部Ａ１１１にて取得した外部通信ログを、許可リストまたは拒否リスト、通常時の統計情報を用いて、外部通信ログに含まれる特定のメッセージが異常であるか否か判定する機能を有する。
　監視情報記憶部Ａ１１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部Ａ１１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部Ａ１１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　監視情報の詳細は後述する。
　このように、アプリ監視部Ａ１１０はアプリ領域のソフトウェアおよび外部通信を監視でき、インターネット接続状態と外部アプリＡ１００のセキュリティ状態を取得できる。外部通信の監視は統計情報を用いた複雑なアルゴリズムになると想定される。
　［制御アプリの構成図］
　図６は、本開示の実施の形態１における制御アプリの構成図を示す図である。
　制御アプリＡ２００は、ＣＡＮ４０を介してゲートウェイＥＣＵ３００と通信するＣＡＮ通信部Ａ２０１と、ＣＡＮ通信とシステムコールを用いて、ＶＭ１００の車両の走る、曲がる、止まるなどの制御を指示する制御アプリ実行部Ａ２０２と、制御アプリのプログラムと設定ファイルを記憶するストレージおよびメモリであるアプリ領域記憶部Ａ２０３と、アプリ監視部Ａ２１０を備える。
　アプリ監視部Ａ２１０は、監視対象取得部Ａ２１１と、システム状態取得部Ａ２１２と、監視部Ａ２１３と、監視情報記憶部Ａ２１４と、監視情報更新部Ａ２１５と、監視結果通知部Ａ２１６を備える。
　監視対象取得部Ａ２１１は、アプリ領域記憶部Ａ２０３から監視対象であるソフトウェアに関する情報を取得し、ＣＡＮ通信部Ａ２０１からＣＡＮ通信ログに関する情報を取得する機能を有する。
　システム状態取得部Ａ２１２は、制御アプリ実行部Ａ２０２から走行状態や起動からの走行距離、起動からの経過時間など車両の状態と、監視部Ａ１１３からセキュリティ状態を、システム状態として取得する機能を有する。
　監視部Ａ２１３は、監視対象取得部Ａ２１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部Ａ２１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。さらに、監視対象取得部Ａ２１１にて取得したＣＡＮ通信ログを、許可リストまたは拒否リスト、通常時の統計情報を用いて、ＣＡＮログに含まれる特定のメッセージが異常であるか否かを判定する機能を有する。
　監視情報記憶部Ａ２１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部Ａ２１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部Ａ２１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　このように、アプリ監視部Ａ２１０はアプリ領域のソフトウェアおよびＣＡＮ通信を監視でき、車両の状態と制御アプリＡ２００のセキュリティ状態を取得できる。ＣＡＮ通信の監視は統計情報を用いた複雑なアルゴリズムになると想定される。
　［映像アプリの構成図］
　図７は、本開示の実施の形態１における映像アプリの構成図を示す図である。
　映像アプリＡ３００は、イーサネット５０を介してＺｏｎｅＥＣＵ５００と通信するイーサネット通信部Ａ３０１と、イーサネット通信とシステムコールを用いて、カメラ映像を取得して、ディスプレイへ映像出力する映像アプリ実行部Ａ３０２と、映像アプリのプログラムと設定ファイルを記憶するストレージおよびメモリであるアプリ領域記憶部Ａ３０３と、アプリ監視部Ａ３１０を備える。
　アプリ監視部Ａ３１０は、監視対象取得部Ａ３１１と、システム状態取得部Ａ３１２と、監視部Ａ３１３と、監視情報記憶部Ａ３１４と、監視情報更新部Ａ３１５と、監視結果通知部Ａ３１６を備える。
　監視対象取得部Ａ３１１は、アプリ領域記憶部Ａ３０３から監視対象であるソフトウェアに関する情報を取得し、イーサネット通信部Ａ３０１からイーサネット通信ログに関する情報を取得する機能を有する。
　システム状態取得部Ａ３１２は、監視部Ａ３１３からセキュリティ状態をシステム状態として取得する機能を有する。
　監視部Ａ３１３は、監視対象取得部Ａ３１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部Ａ３１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。さらに、監視対象取得部Ａ３１１にて取得したイーサネット通信ログを、許可リストまたは拒否リスト、通常時の統計情報を用いて、イーサネット通信ログに含まれる特定のメッセージが異常であるか否かを判定する機能を有する。
　監視情報記憶部Ａ３１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部Ａ３１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部Ａ３１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　このように、アプリ監視部Ａ３１０はアプリ領域のソフトウェアおよびイーサネット通信を監視でき、映像アプリＡ３００のセキュリティ状態を取得できる。イーサネット通信の監視は統計情報を用いた複雑なアルゴリズムになると想定される。
　［外部仮想マシンの構成図］
　図８は、本開示の実施の形態１における外部仮想マシンの構成図を示す図である。
　外部仮想マシンＶＭ１００は、外部アプリ実行部Ａ１０２からシステムコールを受信するアプリ通信部ＶＭ１０１と、システムコールを実行するシステムコール制御部ＶＭ１０２と、外部仮想マシンＶＭ１００のプログラムと、ミドルウェアと、設定ファイルを記憶するストレージおよびメモリであるＶＭ領域記憶部ＶＭ１０３と、ハイパーコールを呼び出すハイパーコール呼出部ＶＭ１０４と、ＶＭ監視部ＶＭ１１０とを備える。
　ＶＭ監視部ＶＭ１１０は、監視対象取得部ＶＭ１１１と、システム状態取得部ＶＭ１１２と、監視部ＶＭ１１３と、監視情報記憶部ＶＭ１１４と、監視情報更新部ＶＭ１１５と、監視結果通知部ＶＭ１１６を備える。
　監視対象取得部ＶＭ１１１は、ＶＭ領域記憶部ＶＭ１０３とアプリ領域記憶部Ａ１０３から監視対象であるソフトウェアに関する情報を取得し、アプリ通信部ＶＭ１０１からシステムコールに関する情報を取得する機能を有する。
　システム状態取得部ＶＭ１１２は、監視部ＶＭ１１３からセキュリティ状態を、システム状態として取得する機能を有する。
　監視部ＶＭ１１３は、監視対象取得部ＶＭ１１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部ＶＭ１１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。さらに、監視対象取得部ＶＭ１１１にて取得したシステムコールログを、許可リストまたは拒否リスト、通常時の統計情報を用いて、システムコールログに含まれる特定のシステムコールが異常であるか否か判定する機能を有する。
　監視情報記憶部ＶＭ１１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部ＶＭ１１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部ＶＭ１１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　このように、ＶＭ監視部ＶＭ１１０はアプリ領域とＶＭ領域のソフトウェアおよびシステムコールを監視でき、外部仮想マシンＶＭ１００と外部アプリＡ１００のセキュリティ状態を取得できる。システムコールの監視は統計情報を用いた複雑なアルゴリズムになると想定される。
　［制御仮想マシンの構成図］
　図９は、本開示の実施の形態１における制御仮想マシンの構成図を示す図である。
　制御仮想マシンＶＭ２００は、制御アプリ実行部Ａ２０２からシステムコールを受信するアプリ通信部ＶＭ２０１と、システムコールを実行するシステムコール制御部ＶＭ２０２と、制御仮想マシンＶＭ２００のプログラムと、ミドルウェアと、設定ファイルを記憶するストレージおよびメモリであるＶＭ領域記憶部ＶＭ２０３と、ハイパーコールを呼び出すハイパーコール呼出部ＶＭ２０４と、ＶＭ監視部ＶＭ２１０とを備える。
　ＶＭ監視部ＶＭ２１０は、監視対象取得部ＶＭ２１１と、システム状態取得部ＶＭ２１２と、監視部ＶＭ２１３と、監視情報記憶部ＶＭ２１４と、監視情報更新部ＶＭ２１５と、監視結果通知部ＶＭ２１６を備える。
　監視対象取得部ＶＭ２１１は、ＶＭ領域記憶部ＶＭ２０３とアプリ領域記憶部Ａ１０３から監視対象であるソフトウェアに関する情報を取得し、アプリ通信部ＶＭ２０１からシステムコールに関する情報を取得する機能を有し、さらに、ハイパーコール制御部ＨＶ１０２からハイパーコールに関する情報を取得する機能を有する。
　システム状態取得部ＶＭ２１２は、監視部ＶＭ２１３からセキュリティ状態を、システム状態として取得する機能を有する。
　監視部ＶＭ２１３は、監視対象取得部ＶＭ２１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部ＶＭ２１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。さらに、監視対象取得部ＶＭ２１１にて取得したシステムコールログを、許可リストまたは拒否リスト、通常時の統計情報を用いて、システムコールログに含まれる特定のシステムコールが異常であるか否か判定する機能を有する。さらに、監視対象取得部ＶＭ２１１にて取得したハイパーコールログを、許可リストまたは拒否リスト、通常時の統計情報を用いて、ハイパーコールログに含まれる特定のハイパーコールが異常であるか否か判定する機能を有する。
　監視情報記憶部ＶＭ２１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部ＶＭ２１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部ＶＭ２１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　このように、ＶＭ監視部ＶＭ２１０はアプリ領域とＶＭ領域のソフトウェアおよびシステムコール、ハイパーコールを監視でき、制御仮想マシンＶＭ２００と制御アプリＡ２００のセキュリティ状態を取得できる。システムコールとハイパーコールの監視は統計情報を用いた複雑なアルゴリズムになると想定される。
　ここで、ハイパーコールの監視は制御仮想マシンＶＭ２００にて実行されると記載しているが、ハイパーバイザＨＶ１００にて実施してもよい。
　［映像仮想マシンの構成図］
　図１０は、本開示の実施の形態１における映像仮想マシンの構成図を示す図である。
　映像仮想マシンＶＭ３００は、映像アプリ実行部Ａ３０２からシステムコールを受信するアプリ通信部ＶＭ３０１と、システムコールを実行するシステムコール制御部ＶＭ３０２と、映像仮想マシンＶＭ３００ンのプログラムと、ミドルウェアと、設定ファイルを記憶するストレージおよびメモリであるＶＭ領域記憶部ＶＭ３０３と、ハイパーコールを呼び出すハイパーコール呼出部ＶＭ３０４と、ＶＭ監視部ＶＭ３１０とを備える。
　ＶＭ監視部ＶＭ３１０は、監視対象取得部ＶＭ３１１と、システム状態取得部ＶＭ３１２と、監視部ＶＭ３１３と、監視情報記憶部ＶＭ３１４と、監視情報更新部ＶＭ３１５と、監視結果通知部ＶＭ３１６を備える。
　監視対象取得部ＶＭ３１１は、ＶＭ領域記憶部ＶＭ３０３とアプリ領域記憶部Ａ３０３から監視対象であるソフトウェアに関する情報を取得し、アプリ通信部ＶＭ３０１からシステムコールに関する情報を取得する機能を有する。
　システム状態取得部ＶＭ３１２は、監視部ＶＭ３１３からセキュリティ状態を、システム状態として取得する機能を有する。
　監視部ＶＭ３１３は、監視対象取得部ＶＭ３１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部ＶＭ３１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。さらに、監視対象取得部ＶＭ３１１にて取得したシステムコールログを、許可リストまたは拒否リスト、通常時の統計情報を用いて、システムコールログに含まれる特定のシステムコールが異常であるか否か判定する機能を有する。
　監視情報記憶部ＶＭ３１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部ＶＭ３１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部ＶＭ３１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　このように、ＶＭ監視部ＶＭ３１０はアプリ領域とＶＭ領域のソフトウェアおよびシステムコールを監視でき、映像仮想マシンＶＭ３００と映像アプリＡ３００のセキュリティ状態を取得できる。システムコールの監視は統計情報を用いた複雑なアルゴリズムになると想定される。
　［ハイパーバイザの構成図］
　図１１は、本開示の実施の形態１におけるハイパーバイザの構成図を示す図である。
　ハイパーバイザＨＶ１００は、ハイパーコール呼出部ＶＭ３０４、ＶＭ３０５、ＶＭ３０６からハイパーコールを受信する仮想マシン通信部ＨＶ１０１と、ハイパーコールを実行するハイパーコール制御部ＨＶ１０２と、ハイパーバイザＨＶ１００のプログラムと、設定ファイルを記憶するストレージおよびメモリであるＨＶ領域記憶部ＨＶ１０３と、ＨＶ監視部ＨＶ１１０とを備える。
　ＨＶ監視部ＨＶ１１０は、監視対象取得部ＨＶ１１１と、システム状態取得部ＨＶ１１２と、監視部ＨＶ１１３と、監視情報記憶部ＨＶ１１４と、監視情報更新部ＨＶ１１５と、監視結果通知部ＨＶ１１６を備える。
　監視対象取得部ＨＶ１１１は、ＨＶ領域記憶部ＨＶ１０３と、ＶＭ領域記憶部ＶＭ１０３と、ＶＭ領域記憶部ＶＭ２０３と、ＶＭ領域記憶部ＶＭ３０３と、から監視対象であるソフトウェアに関する情報を取得する機能を有する。
　システム状態取得部ＨＶ１１２は、仮想マシンのシステム状態と、ＣＰＵ利用率と、メモリ利用率と、監視部ＨＶ１１３からセキュリティ状態を、システム状態として取得する機能を有する。
　監視部ＨＶ１１３は、監視対象取得部ＨＶ１１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部ＨＶ１１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。
　監視情報記憶部ＨＶ１１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部ＨＶ１１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部ＨＶ１１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　このように、ＨＶ監視部ＨＶ１１０は、外部仮想マシンＶＭ１００と制御仮想マシンＶＭ２００と映像仮想マシンＶＭ３００と、ＨＶ領域のソフトウェアを監視でき、外部仮想マシンＶＭ１００と制御仮想マシンＶＭ２００と映像仮想マシンＶＭ３００のシステム状態とセキュリティ状態を取得できる。
　［セキュアアプリの構成図］
　図１２は、本開示の実施の形態１におけるセキュアアプリの構成図を示す図である。
　セキュアアプリＳＡ１００は、ＳＡ監視部ＳＡ１１０と、管理部ＳＡ１２０を備える。
　ＳＡ監視部ＳＡ１１０は、監視対象取得部ＳＡ１１１と、システム状態取得部ＳＡ１１２と、監視部ＳＡ１１３と、監視情報記憶部ＳＡ１１４と、監視情報更新部ＳＡ１１５と、監視結果通知部ＳＡ１１６を備える。
　監視対象取得部ＳＡ１１１は、ＨＶ領域記憶部ＨＶ１０３と、ＶＭ領域記憶部ＶＭ１０３と、ＶＭ領域記憶部ＶＭ２０３と、ＶＭ領域記憶部ＶＭ３０３から監視対象であるソフトウェアに関する情報を取得する機能を有する。
　システム状態取得部ＳＡ１１２は、監視部ＳＡ１１３からセキュリティ状態を、システム状態として取得する機能を有する。
　監視部ＳＡ１１３は、監視対象取得部ＳＡ１１１にて取得したソフトウェアに関する情報の取得値と、監視情報記憶部ＳＡ１１４が記憶する監視情報に含まれる期待値を比較し、取得値と期待値が異なる場合に異常と判定し、取得値と期待値が一致する場合に正常と判定する機能を有する。
　監視情報記憶部ＳＡ１１４は、監視担当と、監視対象と、期待値と、優先度に関する情報が含まれる監視情報を記憶する機能を有する。
　監視情報更新部ＳＡ１１５は、管理部ＳＡ１２０からの要求に応じて監視情報を更新する機能を有する。
　監視結果通知部ＳＡ１１６は、管理部ＳＡ１２０へ監視結果とシステム状態を通知する機能を有する。
　管理部ＳＡ１２０は、監視結果取得部ＳＡ１２１と、システム状態取得部ＳＡ１２２と、監視構成記憶部ＳＡ１２３と、監視変更ルール記憶部ＳＡ１２４と、監視情報変更部ＳＡ１２５と、監視サーバー通信部ＳＡ１２６を備える。
　監視結果取得部ＳＡ１２１は、監視結果通知部Ａ１１６、Ａ２１６、Ａ３１６、ＶＭ１１６、ＶＭ２１６、ＶＭ３１６、ＨＶ１１６、ＳＡ１１６から監視結果を受信する機能を有する。
　システム状態取得部ＳＡ１２２は、監視結果通知部Ａ１１６、Ａ２１６、Ａ３１６、ＶＭ１１６、ＶＭ２１６、ＶＭ３１６、ＨＶ１１６、ＳＡ１１６からシステム状態を受信する機能を有する。
　監視構成記憶部ＳＡ１２３は、複数の多層監視部の信頼チェーン構成パターンを含む監視構成を記憶する機能を有する。
　監視変更ルール記憶部ＳＡ１２４は、システム状態に応じて監視情報に含まれる優先度と監視構成を変更するルールを含む監視変更ルールを記憶する機能を有する。
　監視情報変更部ＳＡ１２５は、監視情報更新部ＳＡ１１５へ監視情報の変更を要求する機能を有する。
　監視サーバー通信部ＳＡ１２６は、監視サーバー１０へ監視結果を通知し、監視サーバー１０から監視情報の変更と監視構成の変更内容と、監視変更ルールの変更の要求を受信し、要求に応答する機能を有する。
　監視構成と監視変更ルールの詳細は後述する。
　このように、ＳＡ監視部ＳＡ１１０は、外部仮想マシンＶＭ１００と制御仮想マシンＶＭ２００と映像仮想マシンＶＭ３００と、ＨＶ領域のソフトウェアを監視でき、外部仮想マシンＶＭ１００と制御仮想マシンＶＭ２００と映像仮想マシンＶＭ３００のセキュリティ状態を取得できる。また、ＳＡ管理部ＳＡ１２０は、システム状態に応じて、適切な監視構成および監視情報に変更できる。
　［監視サーバーの構成図］
　図１３は、本開示の実施の形態１における監視サーバーの構成図を示す図である。
　監視サーバー１０は、車載システム通信部１１と、監視結果表示部１２と、監視構成変更部１３と、監視変更ルール変更部１４と、監視情報変更部１５を備える。
　車載システム通信部１１は、車載システム２０の外部通信部Ａ１０１と通信する機能を有する。
　監視結果表示部１２は、車載システム通信部１１を介して、車載システム２０の外部通信部Ａ１０１から監視結果を受信し、監視結果の情報をグラフィカルユーザーインターフェース上に表示する機能を有する。
　監視構成変更部１３は、監視構成の変更を受け付け、変更の要求を監視サーバー通信部ＳＡ１２６へ送信する。
　監視変更ルール変更部１４は、監視変更ルールの変更を受け付け、変更の要求を監視サーバー通信部ＳＡ１２６へ送信する。
　監視情報変更部１５は、監視情報の変更を受け付け、変更の要求を監視サーバー通信部ＳＡ１２６へ送信する。
　［監視情報の一例］
　図１４－１５は、監視情報の一例を示す図である。
　監視情報は、多層監視部のそれぞれが自身の監視対象を確認し、ソフトウェアおよび通信ログの監視を実施するための情報が記載される。
　図１４において、監視情報は、番号、監視担当、監視対象、メモリ番地、期待値、優先度で構成される。番号は、監視情報を識別するために利用される。監視担当は、監視対象の監視を行う主体者を認識するために利用される。監視対象は、監視の対象となるソフトウェアおよび通信ログを認識するために利用される。メモリ番地は、監視対象を取得するため監視対象が格納されるメモリ番地を認識するために利用される。期待値は、監視対象に関する情報の正常な値を認識するために利用される。優先度は、優先度が高い監視対象ほど重点的に監視するために利用される。優先度の詳細は後述する。
　ここで、アプリ監視部Ａ１１０は外部アプリ監視部、アプリ監視部Ａ２１０は制御アプリ監視部、アプリ監視部Ａ３１０は映像アプリ監視部、ＶＭ監視部ＶＭ１１０は外部ＶＭ監視部、ＶＭ監視部ＶＭ２１０は制御ＶＭ監視部、ＶＭ監視部ＶＭ３１０は映像ＶＭ監視部として記載しており、以下でもこの記載を用いることがある。
　例えば、番号が７である監視情報は、監視担当が外部ＶＭ監視部であり、監視対象がＶＭプログラム１であり、メモリ番地はＶＭ領域Ｂ１０であり、期待値はＢ１０であり、優先度は高である。これは、外部ＶＭ監視部はＶＭプログラム１を重点的に監視し、ＶＭ領域Ｂ１０に格納されるＶＭプログラム１のハッシュ値がＢ１０と一致する場合に正常と判定でき、一致しない場合に異常と判定できる。
　また、例えば、番号が１５である監視情報は、監視担当が制御ＶＭ監視部であり、監視対象がハイパーコールであり、メモリ番地は「―」であり、期待値は「―」であり、優先度は「―」である。これは、制御ＶＭ監視部は、ハイパーコールを監視するが、メモリ番地や期待値、優先度は指定する必要がないことを示している。
　上述の通り、外部通信ログと、ＣＡＮ通信ログと、イーサネット通信ログと、システムコールログと、ハイパーコールログは、例えば、許可リストと拒否リストと正常時の統計情報を用いて異常を判定できる。
　このように、監視情報を用いることで、多層監視部のそれぞれが自身の監視対象を確認し、ソフトウェアおよび通信ログの監視を実施できる。また、監視対象に多層監視部のソフトウェアを含めることによって、多層監視部の監視の信頼チェーンを構築できる。
　図１４において、ＳＡ監視部ＳＡ１１０がＨＶ監視部ＨＶ１１０のソフトウェアを監視し、ＨＶ監視部ＨＶ１１０がＶＭ監視部ＶＭ２１０のソフトウェアを監視し、ＶＭ監視部ＶＭ２１０がＶＭ監視部ＶＭ１１０とＶＭ監視部ＶＭ３１０のソフトウェアを監視し、ＶＭ監視部ＶＭ１１０がアプリ監視部Ａ１１０のソフトウェアを監視し、ＶＭ監視部ＶＭ２１０がアプリ監視部Ａ１１０のソフトウェアを監視し、ＶＭ監視部ＶＭ３１０がアプリ監視部Ａ３１０のソフトウェアを監視することで、多層監視部が信頼可能なＳＡ監視部ＳＡ１１０からアプリケーション監視部まで連結しており、監視の信頼チェーンを構築できていることが分かる。
　図１５には、優先度に応じて、ソフトウェアの監視方法を変更するための情報が記載される。図１５において、優先度、監視周期（分）、検証方法、監視対象選択方法で構成される。優先度は、高、中、低の３種類のうちの一種類が記載され、優先度を識別するために利用される。監視周期（分）は、監視対象の監視処理を行う周期を認識するために利用される。検証方法は、監視対象の監視処理を行う方法を認識するために利用される。監視対象選択方法は、監視対象が複数存在する場合に選択する方法を認識するために利用される。
　例えば、優先度が低である場合は、監視周期（分）が１であり、検証方法が複製値であり、監視対象選択方法が固定である。これは、固定の監視対象を１分間隔で複製値を用いて検証することを示している。固定とは、予め決められた監視対象をすべて監視することであり、複製値とはメモリに格納された監視対象の生データを用いて検証することである。
　これにより、優先度が高い監視対象に対して、精度の高い監視を実施できる。
　また、例えば、優先度が中である場合は、監視対象を特定の順番で、１０分間隔で複製値ではなく複製値にマスクをかけた値であるマスク値を用いて検証することを示している。
　また、例えば、優先度が低である場合は、監視対象をランダムの順番で、１００分間隔で複製値のハッシュ値を用いて検証することを示している。
　ここで、優先度が低である場合、メモリ領域を２以上のブロックに分割し、分割ブロックをランダムで選択して監視対象としてもよい。これにより、処理の負荷を低減できる。
　また、特定の監視周期を設定して、周期が訪れたタイミングで監視を即座に実行するのではなく、周期が訪れたタイミング以降のＣＰＵの空き時間に監視を実行してもよい。この場合、監視タイミングは毎回異なるものの、リアルタイム性が重要視されるシステムへの負担を低減できる。
　また、少なくとも１回の監視が実行される期間を設定してもよい。この場合、所定の期間の間にＣＰＵの空き時間を利用して監視を実行できる。
　また、特定のイベントや特定の監視部の検証結果に応じて、監視タイミングを定義してもよい。例えば、インターネット接続のタイミングで、アプリ監視部Ａ１１０のソフトウェアを監視してもよいし、車両の走行状態が自動走行に変更されたタイミングで制御仮想マシンのソフトウェアを監視してもよいし、セキュリティ異常が１回判定されたタイミングで異常と関連する多層監視部のソフトウェアを監視してもよいし、セキュリティ異常がなく正常と２回判定されたタイミングで連結する監視部のソフトウェアを監視してもよい。
　また、通信ログに関しても、メモリ番地にログが含まれる領域を指定してもよく、期待値に許可リストを指定してもくよく、優先度を指定してもよい。この場合、優先度に応じて、通信ログの監視方法も変更してもよい。
　例えば、優先度が高い場合は、高い精度が期待できるすべてのメッセージのペイロード情報を用いて異常を検知する方法を適用し、優先度が低い場合は、処理負荷の低減が期待できるサンプリングしたメッセージのヘッダ情報を用いて異常を検知する方法を適用する。これにより、優先度に応じて通信ログを重点的に監視できる。
　このように、監視対象に応じて優先度を変更することで、改ざんリスクの高い監視対象を重点的に監視でき、改ざんリスクの低い監視対象は処理負荷を下げて監視できる。
　［システム状態の一例］
　図１６は、システム状態の一例を示す図である。
　システム状態は、管理部ＳＡ１２０が統合ＥＣＵ２００のシステム状態を把握するために利用される。図１６において、システム情報は、番号、分類、システム状態、パラメータで構成される。番号は、システム状態を識別するために利用される。分類は、ネットワーク、ＶＭ、セキュリティ、車両の４種類であり、システム状態を区分するために利用される。システム状態は、具体的なシステム状態の名称が記載され、パラメータはシステム状態を特定するためのパラメータが記載される。
　例えば、番号が５であるシステム状態は、分類がＶＭであり、システム状態がＶＭ状態であり、パラメータが、ＶＭ識別子、オンとオフと再起動中のいずれか一つ、時刻である。つまり、システムの異常やソフトウェアの更新の理由で、特定の仮想マシンが再起動する場合、パラメータには、特定の仮想マシンを識別する識別子と、再起動中という状態、状態を判定した時刻が記載される。
　このように、例えば、番号が１であるシステム状態を確認すれば、統合ＥＣＵ２００がインターネットに接続しているかどうかの状態を把握でき、番号が９であるシステム状態は車両の走行状態を確認すれば、自動運転かどうかの状態を把握でき、番号が７であるシステム状態を確認すれば、ソフトウェア検証の結果として異常と判定された監視対象のソフトウェアの情報を把握できる。
　また、システム状態を統合ＥＣＵ２００に搭載されるタイマー、センサー、その他の機能から収集して参照することで、所定の時間経過と、所定の外部ネットワーク接続時間経過と、システム起動と、システム再起動と、外部ネットワーク接続確立と、外部デバイス接続と、走行モードの切り替えと、給油または給電の終了と、車両診断の実施と、緊急アラートの発呼といったシステム状態を取得できる。
　ここで、図１６のシステム状態は、システム状態のリストと、パラメータに記載すべき項目を示している。リストに含まれるシステム状態を取得した場合に、番号とパラメータを他のプログラムへ通知するまたはログに残すことで、他のプログラムとシステム状態を共有できる。
　［監視構成の一例］
　図１７～図２０は、監視構成の一例を示す図である。
　監視構成は、多層監視部を連結させて監視の信頼チェーンを変更するために利用される。
　図１７において、監視構成は、番号と、監視構成で構成される。番号は、監視構成を識別するために利用され、監視構成は多層監視部の連結パターンが記載される。
　図１７の番号１の監視構成は、ＳＡ監視部ＳＡ１１０がＨＶ監視部ＨＶ１１０のソフトウェアを監視し、ＨＶ監視部ＨＶ１１０がＶＭ監視部ＶＭ２１０のソフトウェアを監視し、ＶＭ監視部ＶＭ２１０がＶＭ監視部ＶＭ１１０とＶＭ監視部ＶＭ３１０のソフトウェアを監視し、ＶＭ監視部ＶＭ１１０がアプリ監視部Ａ１１０のソフトウェアを監視し、ＶＭ監視部ＶＭ２１０がアプリ監視部Ａ１１０のソフトウェアを監視し、ＶＭ監視部ＶＭ３１０がアプリ監視部Ａ３１０のソフトウェアを監視することで、多層監視部が信頼可能なＳＡ監視部ＳＡ１１０からアプリケーション監視部まで連結しており、監視の信頼チェーンを構築できていることが分かる。
　ここで、制御仮想マシンＶＭ２００は、外部ネットワークと直接接続されていないため、外部仮想マシンＶＭ１００よりも信頼できると想定できるため、より信頼度の高い監視部として扱うことができる。
　また、図１７の番号２の監視構成は、ＳＡ監視部ＳＡ１１０がＨＶ監視部ＨＶ１１０の代わりにＶＭ監視部ＶＭ２１０のソフトウェアを監視し、それ以外は番号１の管理構成と同等である。番号１の監視構成と比較すると、ＳＡ監視部ＳＡ１１０の処理とプログラムの複雑性が増加するものの、信頼可能なＳＡ監視部ＳＡ１１０から監視することで、ＶＭ監視部ＶＭ２１０のソフトウェアの信頼度を高めることができる。
　また、図１８の番号３の監視構成は、制御仮想マシンＶＭ２００がシステムダウンした場合であっても監視の信頼チェーン監視を維持可能な監視構成である。もし、制御仮想マシンＶＭ２００がシステムダウンした場合に番号１や番号２の監視構成を継続すると、ＶＭ監視部ＶＭ１１０やＶＭ監視部ＶＭ３１０を監視対象とする監視担当が不在になり、監視の信頼チェーンを維持できない。
　また、図１８の番号４の監視構成は、制御仮想マシンＶＭ２００にて異常が検知された場合であっても、ＶＭ監視部ＶＭ２１０の監視対象を限定してＨＶ監視部ＨＶ１１０へ引き継ぐことで、アプリ監視部Ａ２１０以外の監視の信頼チェーン監視を維持可能な監視構成である。もし、制御仮想マシンＶＭ２００にてセキュリティ異常が検知された場合に番号１や番号２の監視構成を継続すると、制御仮想ＶＭマシン２１０がＶＭ監視部ＶＭ１１０やＶＭ監視部ＶＭ３１０のソフトウェアの監視担当であるが、制御仮想マシンＶＭ２００が改ざんされる可能性が高いため、監視の信頼チェーンを維持できない。
　また、図１９の番号５の監視構成は、制御仮想マシンＶＭ２００にて異常が検知された場合や制御仮想マシンＶＭ２００が改ざんされた場合のリスクが大きい場合に、監視を強化できる監視構成である。ＳＡ監視部ＳＡ１１０とＨＶ監視部ＨＶ１１０の双方からＶＭ監視部ＶＭ２１０のソフトウェアを検証することによって、監視の頻度、信頼度を高めることができる。ここで、２つの監視結果が異なる場合は、信頼度が高いＳＡ監視部ＳＡ１１０の監視結果を採用することができる。
　また、図１９の番号６の監視構成は、制御仮想マシンＶＭ２００にて異常が検知された場合であっても、ＶＭ監視部ＶＭ２１０を監視担当から完全に外し、他仮想マシン監視部にアプリ監視部Ａ１１０の監視を引き継ぐことで、監視の信頼チェーン監視を維持可能な監視構成である。もし、制御仮想マシンＶＭ２００にてセキュリティ異常が検知された場合に番号１や番号２の監視構成を継続すると、制御仮想マシンＶＭ２００がＶＭ監視部ＶＭ１１０やＶＭ監視部ＶＭ３１０のソフトウェアの監視担当であるが、制御仮想マシンＶＭ２００が改ざんされる可能性が高いため、監視の信頼チェーンを維持できない。
　また、図２０の番号７の監視構成は、インターネット接続状態など外部仮想マシンＶＭ１００が改ざんされる可能性が高い場合に、監視を強化できる監視構成である。ＨＶ監視部ＨＶ１１０とＶＭ監視部ＶＭ２１０の双方から、ＶＭ監視部ＶＭ１１０のソフトウェアを検証することによって、監視の頻度、信頼度を高めることができる。ここで、２つの監視結果が異なる場合は、信頼度が高いＨＶ監視部ＨＶ１１０の監視結果を採用することができる。
　このように、複数の監視構成を保持して、システム状態に応じて監視構成を切り替えることによって、ＶＭ異常やセキュリティ異常が発生された場合であっても監視の信頼チェーンの維持が可能であり、システム状態に応じた特定の監視対象の監視の重点化が可能である。
　また、図１７～図２０では閉路のない監視構成のみを記載しているが、ＶＭ監視部ＶＭ２１０がＶＭ監視部ＶＭ３１０のソフトウェアを監視し、ＶＭ監視部ＶＭ３１０がＶＭ監視部ＶＭ１１０のソフトウェアを監視し、ＶＭ監視部ＶＭ１１０がＶＭ監視部ＶＭ２１０のソフトウェアを監視するといった巡回監視の監視構成にしてもよいし、各仮想マシン監視部がその他の仮想マシン監視部のソフトウェアを監視するといった相互監視の監視構成にしてもよい。
　また、複数の監視構成を事前に定義して切り替えるのではなく、動的に監視構成を算出して変更してもよい。例えば、監視部を頂点とし、監視担当を道の始点とし、監視対象を道の終点とする有向グラフとして前記監視構成を記憶し、所定のアルゴリズムで有向グラフを再構築することで、前記監視構成を変更できる。また、例えば、監視部をノードとし、監視担当を親ノードとし、監視対象を子ノードとするツリー構造として前記監視構成を記憶し、所定のアルゴリズムでツリー構造を再構築することで、前記監視構成を変更できる。
　［監視変更ルールの一例］
　図２１は、監視変更ルールの一例を示す図である。
　監視変更ルールは、管理部ＳＡ１２０がシステム状態に応じて監視情報の優先度および監視構成を変更するために利用される。
　図２１において、監視変更ルールは、番号、変更条件、変更処理で構成される。番号は、監視変更ルールを識別するために利用される。変更条件は、変更処理を行うシステム状態であるかを判断するために利用される。変更処理は、監視構成の変更内容について記載される。
　例えば、番号が３である監視変更ルールは、変更条件がインターネット接続確立であり、変更処理がＶＭ監視部ＶＭ１１０とアプリ監視部Ａ１１０に対する監視優先度を一時的に上げるである。つまり、統合ＥＣＵ２００を不正なネットワークに接続させて、不正なソフトウェアをダウンロードさせる攻撃を想定すると、インターネット接続確立の直後はＶＭ監視部ＶＭ１１０とアプリ監視部Ａ１１０のソフトウェアを改ざんされる可能性が高くなる。そのため、一時的に優先度を上げることで、重点的に高頻度で高精度な監視を実施できる。所定時間経過または所定の監視処理が完了した後、一時的に上げた優先度は元の値に戻される。
　また、例えば、番号が１０である監視変更ルールでは、特定の通信において異常が発生した場合、送信元のソフトウェアに異常が発生している可能性が高く、宛先のソフトウェアへ攻撃が展開される可能性が高く、通信の異常を判定した監視部も無効化される可能性が高いため、それぞれ優先度を上げることで重点的に監視ができる。さらに、監視構成を変更することで、複数の監視部から改ざんされる可能性の高いソフトウェアを監視できる。
　また、例えば、番号が６である監視変更ルールでは、特定のＶＭのＣＰＵ使用率が低い場合に、該当ＶＭの処理負荷が大きい監視構成に変更する。これにより、ＣＰＵ使用率が高い仮想マシンに配置された仮想マシン監視部にて多くの監視処理を実施することは他の主要機能へ影響を与える可能性がある。そこで、ＣＰＵ使用率が低い仮想マシン上で動作する仮想マシン監視部が監視を実行することで、リアルタイム性が重要なシステムへの負担を低減できる。
　このように、管理部ＳＡ１２０は、外部ネットワーク接続中か否かと、外部ネットワーク接続確立イベントの発生と、仮想マシンのシステム状態と、多層監視部の監視結果と、異常を検知した監視部の実行権限と、異常を検知したソフトウェアの実行権限と、異常を検知した通信ログの宛先または送信元に応じて、優先度と監視構成を変更できる。
　［監視結果表示の一例］
　図２２及び図２３は、監視結果表示の一例を示す図である。
　監視結果表示は、監視サーバー１０が車載システム２０から監視結果を受信して、監視結果をグラフィカルユーザーインターフェース上に表示することでセキュリティ分析官へ監視情報を伝達するために利用される。
　車載システム２０から受信する監視結果は、システム状態の分類セキュリティの項目と同じであるが、ソフトウェアが正常であった場合には、監視部を特定する識別子と、監視対象のソフトウェアを特定する識別子と、正常判定した時刻が含まれ、ソフトウェアが異常であった場合には、監視部を特定する識別子と、監視対象のソフトウェアを特定する識別子と、異常判定した時刻が含まれ、通信ログが正常であった場合には、監視部を特定する識別子と、通信プロトコルを特定する識別子と、正常な通信メッセージと、正常判定した時刻が含まれ、通信ログが異常であった場合には、監視部を特定する識別子と、通信プロトコルを特定する識別子と、正常な通信メッセージと、異常判定した時刻が含まれる。また、統合ＥＣＵ２００を識別するために、車両を識別する車両ＩＤとＥＣＵを識別するＥＣＵＩＤを監視結果に付与して監視サーバー１０へ送信してもよい。
　図２２において、統合ＥＣＵ２００の抽象化されたシステムアーキテクチャが表示されており、異常と正常の構成要素が強調されて区別できるように表現されており、構成要素の下部に対応する監視結果が表示されている。これにより、セキュリティ分析間は直感的に異常が発生した構成要素を理解することができるため、セキュリティ異常の解析を迅速に実施できる。
　また、図２２において監視構成変更と監視情報変更のボタンがグラフィカルユーザーインターフェースの下部に配置されている。これによって、セキュリティ分析官が監視構成や監視情報の不備やより適切な監視構成を発見した場合に、迅速に車載システム２０へ適用できる。
　また、図２３において、異常が発生した時刻の前後のタイムラインが表示されており、異常と正常の構成要素が強調されて区別できるように表現されており、多層監視部の連結関係を矢印で表現している。これにより、セキュリティ分析間は直感的に異常が発生した時系列を理解することができるため、セキュリティ異常の解析を迅速に実施できる。
　［アプリ監視部の処理のシーケンス］
　図２４は、本開示の実施の形態１におけるアプリ監視部の監視処理のシーケンスを示す図である。
　アプリ監視部Ａ１１０の監視対象取得部Ａ１１１が外部通信ログとアプリ領域のソフトウェア（ＳＷ）のハッシュ値を取得してから、ＳＡ１２１へ監視結果を通知するまでの処理シーケンスを示している。図２４では、外部アプリＡ１００を例に上げて説明するが、制御アプリＡ２００、映像アプリＡ３００の場合は通信ログの種類が異なる以外は同様の処理のシーケンスであるため説明を割愛する。
　（Ｓ２４０１）アプリ監視部Ａ１１０の監視対象取得部Ａ１１１は、外部通信部Ａ１０１から外部通信ログである通信ログを取得し、監視部Ａ１１３へ送信する。
　（Ｓ２４０２）監視部Ａ１１３は、通信ログに異常が含まれているかを判定し、監視結果通知部Ａ１１６へ監視結果を通知する。ここで、監視結果には、ソフトウェアが正常であった場合には、監視部を特定する識別子と、監視対象のソフトウェアを特定する識別子と、判定時刻が含まれ、ソフトウェアが異常であった場合には、監視部を特定する識別子と、監視対象のソフトウェアを特定する識別子と、判定時刻が含まれ、通信が正常であった場合には、監視部を特定する識別子と、通信プロトコルを特定する識別子と、判定時刻が含まれる。
　（Ｓ２４０３）監視結果通知部Ａ１１６は、監視結果取得部ＳＡ１２１へ監視結果を通知する。
　（Ｓ２４０４）監視結果取得部ＳＡ１２１は、監視結果を取得する。
　（Ｓ２４０５）監視対象取得部Ａ１１１は、監視情報記憶部Ａ１１４に記載された監視対象の優先度に従って、一定の時間が経過する度に、アプリ領域記憶部Ａ１０３に格納されたソフトウェアのハッシュ値を取得し、監視情報記憶部Ａ１１４に格納されたソフトウェアのハッシュ値の期待値を取得し、監視部Ａ１１３へ送信する。
　（Ｓ２４０６）監視部Ａ１１３は、取得値と期待値が一致する場合は正常と判定し、一致しない場合は異常と判定し、監視結果通知部Ａ１１６へ監視結果を通知する。
　（Ｓ２４０７）監視結果通知部Ａ１１６は、監視結果取得部ＳＡ１２１へ監視結果を通知する。
　（Ｓ２４０８）監視結果取得部ＳＡ１２１は、監視結果を取得する。
　［仮想マシン監視部の処理のシーケンス］
　図２５は、本開示の実施の形態１における仮想マシン監視部の監視処理のシーケンスを示す図である。
　ＶＭ監視部ＶＭ２１０の監視対象取得部ＶＭ２１１がシステムコールとハイパーコールとアプリ領域のソフトウェアと、ＶＭ領域のソフトウェアのハッシュ値を取得してから、ＳＡ１２１へ監視結果を通知するまでの処理シーケンスを示している。
　図２５では、ＶＭ監視部ＶＭ２１０を例に上げて説明するが、ＶＭ監視部ＶＭ１１０、ＶＭ監視部ＶＭ３１０の場合はハイパーコールを取得しない点以外は同様の処理のシーケンスであるため説明を割愛する。
　（Ｓ２５０１）ＶＭ監視部ＶＭ２１０の監視対象取得部ＶＭ２１１は、システムコール制御部ＶＭ２０２とハイパーバイザＨＶ１００のハイパーコール制御部ＨＶ１０２からそれぞれシステムコールとハイパーコールである通信ログを取得し、監視部ＶＭ２１３へ送信する。
　（Ｓ２５０２）監視部ＶＭ２１３は、通信ログに異常が含まれているかを判定し、監視結果通知部ＶＭ２１６へ監視結果を通知する。
　（Ｓ２５０３）監視結果通知部ＶＭ２１６は、監視結果取得部ＳＡ１２１へ監視結果を通知する。
　（Ｓ２５０４）監視結果取得部ＳＡ１２１は、監視結果を取得する。
　（Ｓ２５０５）監視対象取得部ＶＭ２１１は、監視情報記憶部ＶＭ２１４に記載された監視対象の優先度に従って、一定の時間が経過する度に、ＶＭ領域記憶部ＶＭ１０３、２０３、３０３に格納されたソフトウェアのハッシュ値を取得し、監視情報記憶部ＶＭ２１４に格納されたソフトウェアのハッシュ値の期待値を取得し、監視部ＶＭ２１３へ送信する。
　（Ｓ２５０６）監視部ＶＭ２１３は、取得値と期待値が一致する場合は正常と判定し、一致しない場合は異常と判定し、監視結果通知部ＨＶ１１６へ監視結果を通知する。
　（Ｓ２５０７）監視結果通知部ＶＭ２１６は、監視結果取得部ＳＡ１２１へ監視結果を通知する。
　（Ｓ２５０８）監視結果取得部ＳＡ１２１は、監視結果を取得する。
　［ハイパーバイザ監視部の処理のシーケンス］
　図２６は、本開示の実施の形態１におけるハイパーバイザの監視処理のシーケンスを示す図である。
　ＨＶ監視部ＨＶ１１０の監視対象取得部ＨＶ１１１が、ＶＭ領域のソフトウェアとＨＶ領域のソフトウェアのハッシュ値を取得してから、ＳＡ１２１へ監視結果を通知するまでの処理シーケンスを示している。
　（Ｓ２６０１）ＨＶ監視部ＨＶ１１０の監視対象取得部ＨＶ１１１は、監視情報記憶部ＨＶ１１４に記載された監視対象の優先度に従って、一定の時間が経過する度に、ＶＭ領域記憶部ＶＭ１０３、２０３、３０３とＨＶ領域記憶部ＨＶ１０３に格納されたソフトウェアのハッシュ値を取得し、監視情報記憶部ＨＶ１１４に格納されたソフトウェアのハッシュ値の期待値を取得し、監視部ＨＶ１１３へ送信する。
　（Ｓ２６０２）監視部ＨＶ１１３は、取得値と期待値が一致する場合は正常と判定し、一致しない場合は異常と判定し、監視結果通知部ＨＶ１１６へ監視結果を通知する。
　（Ｓ２６０３）監視結果通知部ＨＶ１１６は、監視結果取得部ＳＡ１２１へ監視結果を通知する。
　（Ｓ２６０４）監視結果取得部ＳＡ１２１は、監視結果を取得する。
　［セキュアアプリ監視部の処理のシーケンス］
　図２７は、本開示の実施の形態１におけるセキュアアプリの監視処理のシーケンスを示す図である。
　ＳＡ監視部ＳＡ１１０の監視対象取得部ＳＡ１１１が、ＶＭ領域のソフトウェアとＨＶ領域のソフトウェアのハッシュ値を取得してから、ＳＡ１２１へ監視結果を通知するまでの処理シーケンスを示している。
　（Ｓ２７０１）ＳＡ監視部ＳＡ１１０の監視対象取得部ＳＡ１１１は、監視情報記憶部ＳＡ１１４に記載された監視対象の優先度に従って、一定の時間が経過する度に、ＶＭ領域記憶部ＶＭ１０３、２０３、３０３とＨＶ領域記憶部ＨＶ１０３に格納されたソフトウェアのハッシュ値を取得し、監視情報記憶部ＳＡ１１４に格納されたソフトウェアのハッシュ値の期待値を取得し、監視部ＳＡ１１３へ送信する。
　（Ｓ２７０２）監視部ＳＡ１１３は、取得値と期待値が一致する場合は正常と判定し、一致しない場合は異常と判定し、監視結果通知部ＳＡ１１６へ監視結果を通知する。
　（Ｓ２７０３）監視結果通知部ＳＡ１１６は、監視結果取得部ＳＡ１２１へ監視結果を通知する。
　（Ｓ２７０４）監視結果取得部ＳＡ１２１は、監視結果を取得する。
　［監視サーバー通知処理のシーケンス］
　図２８は、本開示の実施の形態１における監視サーバー通知処理のシーケンスを示す図である。
　ＳＡ監視部ＳＡ１１０の監視結果取得部ＳＡ１２１が、アプリケーション監視部、仮想マシン監視部、ＨＶ監視部ＨＶ１１０、ＳＡ監視部ＳＡ１１０から監視結果を取得し、監視サーバー１０の監視結果表示部１２が監視結果を表示するまでの処理シーケンスを示している。
　（Ｓ２８０１）ＳＡ監視部ＳＡ１１０の監視結果取得部ＳＡ１２１が、アプリケーション監視部、仮想マシン監視部、ＨＶ監視部ＨＶ１１０、ＳＡ監視部ＳＡ１１０から監視結果を取得し、監視サーバー通信部ＳＡ１２６へ送信する。
　（Ｓ２８０２）監視サーバー通信部ＳＡ１２６は、外部通信部Ａ１０１を介して、監視サーバー１０の車載システム通信部１１へ監視結果を通知する。
　（Ｓ２８０３）車載システム通信部１１は、監視結果を受信して、監視結果表示部１２へ送信する。
　（Ｓ２８０４）監視結果表示部１２は、監視結果を表示する。
　［監視情報変更処理のシーケンス］
　図２９は、本開示の実施の形態１における監視情報変更処理のシーケンスを示す図である。
　ＳＡ監視部ＳＡ１１０のシステム状態取得部ＳＡ１２２が、アプリケーション監視部、仮想マシン監視部、ＨＶ監視部ＨＶ１１０、ＳＡ監視部ＳＡ１１０からセキュリティ状態を取得し、アプリケーション監視部、仮想マシン監視部、ＨＶ監視部ＨＶ１１０、ＳＡ監視部ＳＡ１１０の監視情報を更新するまでの処理シーケンスを示している。
　（Ｓ２９０１）ＳＡ監視部ＳＡ１１０のシステム状態取得部ＳＡ１２２が、アプリケーション監視部、仮想マシン監視部、ＨＶ監視部ＨＶ１１０、ＳＡ監視部ＳＡ１１０からセキュリティ状態を取得し、監視情報変更部ＳＡ１２５へ送信する。
　（Ｓ２９０２）監視情報変更部ＳＡ１２５は、監視変更ルール記憶部ＳＡ１２４に格納された監視変更ルールを確認し、システム状態が監視変更ルールの変更条件と一致する場合、変更処理を実施し、監視情報更新部Ａ１１５、Ａ２１５、Ａ３１５、ＶＭ１１５、ＶＭ２１５、ＶＭ３１５、ＨＶ１１５、ＳＡ１１５へ変更を要求する。
　（Ｓ２９０３）監視情報更新部Ａ１１５、Ａ２１５、Ａ３１５、ＶＭ１１５、ＶＭ２１５、ＶＭ３１５、ＨＶ１１５、ＳＡ１１５は監視情報を更新する。
　ここで、監視情報と監視構成は、監視サーバー１０からも変更可能である。その場合、監視サーバー通信部ＳＡ１２６は、監視サーバー１０から変更情報を受信し、監視情報変更部ＳＡ１２５へ送信する。そして、監視情報変更部ＳＡ１２５が、監視構成記憶部ＳＡ１２３に含まれる構成情報を更新し、監視情報更新部Ａ１１５、Ａ２１５、Ａ３１５、ＶＭ１１５、ＶＭ２１５、ＶＭ３１５、ＨＶ１１５、ＳＡ１１５のへ監視情報の変更を要求することで実現する。
　［監視処理のフローチャート］
　図３０に、本開示の実施の形態１における監視処理のフローチャートを示す。
　図３０では、アプリ監視部Ａ１１０を例に挙げて説明するが、他のアプリケーション監視部、仮想マシン監視部、ＨＶ監視部ＨＶ１１０、ＳＡ監視部ＳＡ１１０であっても通信ログの種類と、ソフトウェアの種類が異なる以外は同様である。
　（Ｓ３００１）アプリ監視部Ａ１１０の監視対象取得部Ａ１１１は監視対象である外部通信ログとソフトウェアのハッシュ値を取得し、Ｓ３００２とＳ３００５を実施する。
　（Ｓ３００２）監視部Ａ１１３は、Ｓ３００１にて取得した外部通信ログに異常が含まれるか判定し、異常が含まれる場合にＳ３００３を実施し、異常が含まれない場合にＳ３００４を実施する。
　（Ｓ３００３）監視部Ａ１１３は、監視対象の通信は異常であるとしてシステム状態を更新、Ｓ３００５を実施する。
　（Ｓ３００４）監視部Ａ１１３は、監視対象の通信は正常であるとしてシステム状態を更新し、Ｓ３００５を実施する。
　（Ｓ３００５）監視結果通知部Ａ１１６は、監視結果とシステム状態を監視結果取得部ＳＡ１２１へ通知し、終了する。
　（Ｓ３００６）監視部Ａ１１３は、ソフトウェアに異常が含まれるか判定し、異常が含まれる場合、Ｓ３００７を実施し、異常が含まれない場合、Ｓ３００８を実施する。
　（Ｓ３００７）監視部Ａ１１３は、監視対象のソフトウェアは異常であるとしてシステム状態を更新、Ｓ３００５を実施する。
　（Ｓ３００８）監視部Ａ１１３は、監視対象のソフトウェアは正常であるとしてシステム状態を更新し、Ｓ３００５を実施する。
　［監視変更処理のフローチャート］
　図３１に、本開示の実施の形態１における監視変更処理のフローチャートを示す。
　（Ｓ３１０１）管理部ＳＡ１２０のシステム状態取得部ＳＡ１２２はシステム状態を取得し、Ｓ３１０２を実施する。
　（Ｓ３１０２）監視情報変更部ＳＡ１２５は、監視変更ルール記憶部ＳＡ１２４に格納される監視変更ルールを確認し、Ｓ３１０１にて取得したシステム状態が、監視変更ルールの変更条件に一致するかを判定し、一致する場合にＳ３１０３を実施し、一致しない場合に終了する。
　（Ｓ３１０３）監視情報変更部ＳＡ１２５は、Ｓ３１０２にて一致した監視変更ルールに記載される変更処理を実施し、監視情報更新部Ａ１１５、Ａ２１５、Ａ３１５、ＶＭ１１５、ＶＭ２１５、ＶＭ３１５、ＨＶ１１５、ＳＡ１１５のへ監視情報の変更を要求し、終了する。
　［統合ＥＣＵの構成図の詳細の変形例１］
　図３２は、本開示の実施の形態１における統合ＥＣＵの構成図の詳細の変形例１を示す図である。図４では、仮想ソフトウェア基盤としてタイプ１のハイパーバイザＨＶ１００の利用を想定して記載しているが、タイプ２のハイパーバイザＨＶ２００を用いてもよい。この場合、ホストオペレーティングシステムＨＯＳ１００がハイパーバイザＨＶ２００を起動し、ハイパーバイザＨＶ２００が仮想マシンを起動する。
　ハイパーバイザＨＶ２００は、ＨＶ領域のソフトウェアとＶＭ領域のソフトウェアを監視するＨＶ監視部ＨＶ２１０を備え、ホストオペレーティングシステムＨＯＳ１００は、ホストＯＳ領域のソフトウェアとＨＶ領域のソフトウェアとＶＭ領域のソフトウェア、システムコールを監視するホストＯＳ監視部ＨＯＳ１１０を備える。
　各プログラムの実行権限について説明する。図４と同様に、セキュアオペレーティングシステムに、最も強いセキュアな実行権限（ＰＬ４）を割り当て、オペレーティングシステム上のアプリケーションに次に強いセキュアな実行権限（ＰＬ３）を割り当てる。図４とは異なり、ホストオペレーティングシステムＨＯＳ１００に強い実行権限（ＰＬ１）を割り当て、ハイパーバイザＨＶ２００と、仮想マシンにホストオペレーティングシステムＨＯＳ１００と同じ実行権限（ＰＬ１）を割り当てる。そして、図４と同様に、仮想マシン上のアプリケーション（ＰＬ０）に最も弱い実行権限を割り当てる。
　この場合、外部ネットワークと接続される外部アプリＡ１００が改ざんされる可能性が最も高いため信頼度が最も低く、次に実行権限が弱い制御アプリＡ２００、映像アプリＡ３００の信頼度が低く、次に実行権限が弱い外部仮想マシンＶＭ１００、制御仮想マシンＶＭ２００、映像仮想マシンＶＭ３００、ハイパーバイザＨＶ２００、ホストオペレーティングシステムＨＯＳ１００の信頼度が低く、セキュアアプリＳＡ１００、セキュアオペレーティングシステムＳＯＳ１００の信頼度が最も高いと想定できる。また、ホストオペレーティングシステムＨＯＳ１００は外部仮想マシンへ外部ネットワークインタフェースをブリッジなどの手段で提供する場合、ホストオペレーティングシステムＨＯＳ１００は外部ネットワークと接続される可能性があり、ホストオペレーティングシステムＨＯＳ１００から仮想マシンへ提供するストレージへアクセスできる可能性もあることから、図４におけるハイパーバイザＨＶ２００とは異なり、ソフトウェアの信頼度は低い。そのため、セキュアアプリから、ホストオペレーティングシステムＨＯＳ１００だけでなく、ハイパーバイザＨＶ２００、仮想マシンのソフトウェアを監視することが望ましい。
　アプリケーション、仮想マシン、ハイパーバイザＨＶ２００、ホストオペレーティングシステムＨＯＳ１００、セキュアアプリＳＡ１００それぞれにセキュリティ対策機構を導入することが望ましいが、セキュリティ対策機構自体が改ざんされるリスクが課題となる。そこで、例えば、ＳＡ監視部ＳＡ１１０がホストＯＳ監視部ＨＯＳ１１０のソフトウェアと、ＨＶ監視部ＨＶ２１０のソフトウェアと、仮想マシンのソフトウェアを監視し、仮想マシン監視部がアプリケーション監視部を監視してもいい。
　このように、それぞれの監視部を、より強い実行権限で動作する少なくとも１つの多層監視部から監視することで、監視の信頼チェーンを構築できる。これによって、ホストオペレーティングシステムＨＯＳ１００やハイパーバイザＨＶ２００が乗っ取られた場合であっても、ＳＡ監視部ＳＡ１１０から異常を検知できる。
　なお、ハイパーバイザＨＶ２００にホストオペレーティングシステムＨＯＳ１００より強い実行権限（ＰＬ２）を割り当ててもよい。この場合、実行権限と信頼度と監視の信頼チェーンについては図４の説明と同様になる。
　［統合ＥＣＵの構成図の詳細の変形例２］
　図３３は、本開示の実施の形態１における統合ＥＣＵの構成図の詳細の変形例２を示す図である。図４では、ハイパーバイザＨＶ１００が３種類の仮想マシンを実行および監視を実施する記載しているが、ハイパーバイザＨＶ１００ホストするコンテナ仮想マシンＶＭ４００がコンテナ仮想化基盤であるコンテナエンジンＣＥ１００を用いて、アプリケーション層を仮想化して、コンテナアプリＣＡ１００とコンテナアプリＣＡ２００を動作させることが想定できる。
　コンテナ仮想マシンＶＭ４００は、コンテナエンジンＣＥ１００のソフトウェアと、コンテナアプリＣＡ１００のソフトウェアと設定と、コンテナアプリＣＡ２００のソフトウェアと設定を含むＶＭ領域のソフトウェアを監視するＶＭ監視部ＶＭ４１０を備え、コンテナアプリＣＡ２００は、アプリ領域のソフトウェアと、コンテナアプリＣＡ１００と、コンテナ間通信を監視するコンテナアプリ監視部ＣＡ２１０を備える。
　各プログラムの実行権限について説明する。図４と同様に、セキュアオペレーティングシステムに、最も強いセキュアな実行権限（ＰＬ４）を割り当て、オペレーティングシステム上のアプリケーションに次に強いセキュアな実行権限（ＰＬ３）を割り当て、ハイパーバイザＨＶ１００に次に強い実行権限（ＰＬ２）を割り当て、仮想マシンに次に強い実行権限（ＰＬ１）を割り当てる。コンテナエンジンＣＥ１００と、コンテナアプリＣＡ１００と、コンテナアプリＣＡ２００には最も弱い実行権限を割り当てる。
　ここで、同じ実行権限で動作する複数のコンテナは信頼度が異なると想定してもよい。例えば、コンテナアプリＣＡ１００がＷｉ－ＦｉやＢｌｕｅｔｏｏｔｈなどの近接ネットワークと通信する機能を有し、コンテナアプリＣＡ２００が車両の制御機能を有する場合、ソフトウェアが改ざんされる可能性を考慮すると、コンテナアプリＣＡ１００よりコンテナアプリＣＡ２００の信頼度が高いと考えられる。この場合、コンテナアプリ監視部ＣＡ２１０から、コンテナアプリＣＡ１００のソフトウェアを監視することで、監視の信頼チェーンを同一の実行権限で動作するコンテナ間であっても構築できる。
　この場合、外部ネットワークと接続される外部アプリＡ１００が改ざんされる可能性が最も高いため信頼度が最も低く、次に実行権限が弱いが近接ネットワークを介した通信を直接行うコンテナアプリＣＡ２００の信頼度が低く、次に実行権限は同じであるがネットワークを介した通信を直接行わないコンテナアプリＣＡ１００と、コンテナエンジンＣＥ１００の信頼度が低く、次に実行権限が弱い外部仮想マシンＶＭ１００、及び、コンテナ仮想マシンＶＭ４００の信頼度が低く、次に実行権限が弱いハイパーバイザＨＶ１００の信頼度が低くセキュアアプリＳＡ１００、及び、セキュアオペレーティングシステムＳＯＳ１００の信頼度が最も高いと想定できる。
　アプリケーション、仮想マシン、ハイパーバイザＨＶ１００、コンテナ仮想マシンＶＭ４００、コンテナアプリＣＡ１００、コンテナアプリＣＡ２００それぞれに対策機構を導入することが望ましいが、セキュリティ対策機構自体が改ざんされるリスクが課題となる。そこで、例えば、ＳＡ監視部ＳＡ１１０がＨＶ監視部ＨＶ１１０のソフトウェアと、仮想マシンのソフトウェアを監視し、ＶＭ監視部ＶＭ４１０がコンテナエンジンＣＥ１００と、コンテナアプリＣＡ１００、コンテナアプリＣＡ２００と、コンテナアプリ監視部ＣＡ２１０を監視し、アプリ監視のソフトウェアと、コンテナアプリＣＡ１００と、コンテナ間通信を監視するコンテナアプリ監視部ＣＡ２１０がアプリ監視のソフトウェアと、コンテナアプリＣＡ１００と、コンテナ間通信を監視することで、それぞれの監視部を、より強い実行権限またはより高い信頼度で動作する少なくとも１つの多層監視部から監視できるため、監視の信頼チェーンを構築できる。
　なお、ハイパーバイザＨＶ１００を用いることは必須でなく、ホストとなるオペレーティングシステムが、アプリケーションをコンテナエンジンＣＥ１００によって仮想化して、コンテナアプリＣＡ１００とコンテナアプリＣＡ２００を動作させてもよい。この場合、実行権限と信頼度と監視の信頼チェーンについては、ハイパーバイザＨＶ１００を削除し、コンテナ仮想マシンＶＭ４００にホストとなるオペレーティングシステムに置き換えることで、図３３の説明と同様である。
　（他の実施の形態）
　以上のように、本開示に係る技術の例示として実施の形態１を説明した。しかしながら、本開示に係る技術は、これに限定されず、適宜、変更、置き換え、付加、省略等を行った実施の形態にも適用可能である。例えば、以下のような変形例も本開示の一実施態様に含まれる。
　（１）上記の実施の形態では、自動車に搭載される車載システムにおけるセキュリティ対策として説明したが、適用範囲はこれに限られない。自動車に限らず、建機、農機、船舶、鉄道、飛行機などのモビリティにも適用してもよい。すなわち、モビリティシステムにおけるセキュリティ対策として適用可能である。また、工場やビルなどの産業制御システムに適用してもよい。
　（２）上記の実施の形態では、通信ログとしてセキュアアプリの通信に利用されるセキュアモニタコールを用いていないが、ＶＭ監視部ＶＭ２１０、ＨＶ監視部ＨＶ１１０またはＳＡ監視部ＳＡ１１０、監視対象としてもよい。これにより、セキュアアプリおよびセキュアＯＳが記憶する秘密情報への攻撃試行を補足できる効果がある。
　（３）上記の実施の形態では、セキュアオペレーティングシステムＳＯＳ１００に監視部を実装しない構成のみを記載しているが、監視部を実装してもよい。この場合、セキュアオペレーティングシステムＳＯＳ１００では、脆弱性を含まない実装が求められるため、セキュアアプリのソフトウェアを検証するだけの単純なアルゴリズムの実装が望ましい。
　（４）上記の実施の形態では、ハイパーバイザＨＶ１００は、３種類の仮想マシンを実行および管理すると記載しているが、３種類でなくとも、３未満の仮想マシンであっても、４以上の仮想マシンであってもよい。
　（５）上記の実施の形態では、４種類の実行権限を割り当てると記載しているが、４種類でなくとも、４種類未満であっても、５種類以上であってもよい。
　（６）上記の実施の形態では、外部ネットワークへの接続または、車両の制御の機能の有無に応じて、仮想マシンの信頼度が異なると説明しているが、ユーザログイン機能の有無または、第三者アプリのダウンロード機能の有無に応じて仮想マシンの信頼度が異なっても良い。この場合、ユーザログイン機能を有する場合は、不正ログインされる可能性があるため信頼度は低く、第三者アプリのダウンロード機能を有する場合は、不正ソフトウェアをダウンロードされる可能性があるため信頼度は低いと想定できる。
　（７）上記の実施の形態では、すべての仮想マシンとすべてのアプリケーションとハイパーバイザＨＶ１００とセキュアアプリＳＡ１００に監視部を配置するとして記載しているが、これらの配置は必須でなく、実行権限または仮想マシンの信頼度が異なる２以上の監視部が配置されていればよい。
　（８）上記実施の形態における各装置を構成する構成要素の一部又は全部は、１個のシステムＬＳＩ（Ｌａｒｇｅ　Ｓｃａｌｅ　Ｉｎｔｅｇｒａｔｉｏｎ：大規模集積回路）から構成されているとしても良い。システムＬＳＩは、複数の構成部を１個のチップ上に集積して製造された超多機能ＬＳＩであり、具体的には、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等を含んで構成されるコンピュータシステムである。ＲＡＭには、コンピュータプログラムが記録されている。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、システムＬＳＩは、その機能を達成する。また、上記各装置を構成する構成要素の各部は、個別に１チップ化されていても良いし、一部又は全部を含むように１チップ化されても良い。また、ここでは、システムＬＳＩとしたが、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現しても良い。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ　Ｐｒｏｇｒａｍｍａｂｌｅ　Ｇａｔｅ　Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。更には、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行っても良い。バイオ技術の適用等が可能性としてあり得る。
　（９）上記各装置を構成する構成要素の一部又は全部は、各装置に脱着可能なＩＣカード又は単体のモジュールから構成されているとしても良い。ＩＣカード又はモジュールは、マイクロプロセッサ、ＲＯＭ、ＲＡＭ等から構成されるコンピュータシステムである。ＩＣカード又はモジュールは、上記の超多機能ＬＳＩを含むとしても良い。マイクロプロセッサが、コンピュータプログラムに従って動作することにより、ＩＣカード又はモジュールは、その機能を達成する。このＩＣカード又はこのモジュールは、耐タンパ性を有するとしてもよい。
　（１０）本開示の一態様としては、異常検知の方法をコンピュータにより実現するプログラム（コンピュータプログラム）であるとしても良いし、コンピュータプログラムからなるデジタル信号であるとしても良い。また、本開示の一態様としては、コンピュータプログラム又はデジタル信号をコンピュータで読み取り可能な記録媒体、例えば、フレキシブルディスク、ハードディスク、ＣＤ－ＲＯＭ、ＭＯ、ＤＶＤ、ＤＶＤ－ＲＯＭ、ＤＶＤ－ＲＡＭ、ＢＤ（Ｂｌｕｅ―ｒａｙ（登録商標）　Ｄｉｓｃ）、半導体メモリ等に記録したものとしても良い。また、これらの記録媒体に記録されているデジタル信号であるとしても良い。また、本開示の一態様としては、コンピュータプログラム又はデジタル信号を、電気通信回線、無線又は有線通信回線、インターネットを代表とするネットワーク、データ放送等を経由して伝送するものとしても良い。また、本開示の一態様としては、マイクロプロセッサとメモリを備えたコンピュータシステムであって、メモリは、上記コンピュータプログラムを記録しており、マイクロプロセッサは、コンピュータプログラムに従って動作するとしても良い。また、プログラム若しくはデジタル信号を記録媒体に記録して移送することにより、又は、プログラム若しくはデジタル信号を、ネットワーク等を経由して移送することにより、独立した他のコンピュータシステムにより実施するとしてもよい。
　（１１）上記実施の形態及び上記変形例で示した各構成要素及び機能を任意に組み合わせることで実現される形態も本開示の範囲に含まれる。
　本開示の監視装置によれば、車載システムに攻撃者が侵入し、信頼度が低い領域に実装された監視プログラムが改ざんされて無効化された場合であっても、車載システムに発生した異常を検知できる。これにより、安全な自動運転や先進運転支援システムを提供することを目的とする。
　１０　監視サーバー
　１１　車載システム通信部
　１２　監視結果表示部
　１３　監視構成変更部
　１４　監視変更ルール変更部
　１５　監視情報変更部
　２０　車載システム
　３０　外部ネットワーク
　４０、４１　ＣＡＮ
　５０、５１　イーサネット
　２００　統合ＥＣＵ
　３００　ゲートウェイＥＣＵ
　４００ａ　ステアリングＥＣＵ
　４００ｂ　ブレーキＥＣＵ
　５００　ＺｏｎｅＥＣＵ
　６００ａ　フロントカメラＥＣＵ
　６００ｂ　リアカメラＥＣＵ
　Ａ１００　外部アプリ
　Ａ１０１　外部通信部
　Ａ１０２　外部アプリ実行部
　Ａ１０３、Ａ２０３、Ａ３０３　アプリ領域記憶部
　Ａ１１０、Ａ２１０、Ａ３１０　アプリ監視部
　Ａ１１１、Ａ２１１、Ａ３１１、ＶＭ１１１、ＶＭ２１１、ＶＭ３１１、ＨＶ１１１、ＳＡ１１１　監視対象取得部
　Ａ１１２、Ａ２１２、Ａ３１２、ＶＭ１１２、ＶＭ２１２、ＶＭ３１２、ＨＶ１１２、ＳＡ１１２　システム状態取得部
　Ａ１１３、Ａ２１３、Ａ３１３、ＶＭ１１３、ＶＭ２１３、ＶＭ３１３、ＨＶ１１３、ＳＡ１１３　監視部
　Ａ１１４、Ａ２１４、Ａ３１４、ＶＭ１１４、ＶＭ２１４、ＶＭ３１４、ＨＶ１１４、ＳＡ１１４　監視情報記憶部
　Ａ１１５、Ａ２１５、Ａ３１５、ＶＭ１１５、ＶＭ２１５、ＶＭ３１５、ＨＶ１１５、ＳＡ１１５　監視情報更新部
　Ａ１１６、Ａ２１６、Ａ３１６、ＶＭ１１６、ＶＭ２１６、ＶＭ３１６、ＨＶ１１６、ＳＡ１１６　監視結果通知部
　Ａ２００　制御アプリ
　Ａ２０１　ＣＡＮ通信部
　Ａ２０２　制御アプリ実行部
　Ａ３００　映像アプリ
　Ａ３０１　イーサネット通信部
　Ａ３０２　映像アプリ実行部
　ＣＡ１００、ＣＡ２００　コンテナアプリ
　ＣＡ２１０　コンテナアプリ監視部
　ＨＶ１００、ＨＶ２００　ハイパーバイザ
　ＨＶ１０１　仮想マシン通信部
　ＨＶ１０２　ハイパーコール制御部
　ＨＶ１０３　ＨＶ領域記憶部
　ＨＶ１１０、ＨＶ２１０　ＨＶ監視部
　ＨＯＳ１００　ホストオペレーティングシステム
　ＨＯＳ１１０　ホストＯＳ監視部
　ＳＡ１００　セキュアアプリ
　ＳＡ１１０　ＳＡ監視部
　ＳＡ１２０　管理部
　ＳＡ１２１　監視結果取得部
　ＳＡ１２２　システム状態取得部
　ＳＡ１２３　監視構成記憶部
　ＳＡ１２４　監視変更ルール記憶部
　ＳＡ１２５　監視情報変更部
　ＳＡ１２６　監視サーバー通信部
　ＳＯＳ１００　セキュアオペレーティングシステム
　ＶＭ１００　外部仮想マシン
　ＶＭ１０１、ＶＭ２０１、ＶＭ３０１　アプリ通信部
　ＶＭ１０２、ＶＭ２０２、ＶＭ３０２　システムコール制御部
　ＶＭ１０３、ＶＭ２０３、ＶＭ３０３　ＶＭ領域記憶部
　ＶＭ１０４、ＶＭ２０４、ＶＭ３０４　ハイパーコール呼出部
　ＶＭ１１０、ＶＭ２１０、ＶＭ３１０、ＶＭ４１０　ＶＭ監視部
　ＶＭ２００　制御仮想マシン
　ＶＭ３００　映像仮想マシン
　ＶＭ４００　コンテナ仮想マシン

Claims (27)

  1. 　ソフトウェアと通信ログのうち少なくとも１つを監視対象として監視する２以上の監視部を備え、
    　前記監視部は、それぞれ２種類の実行権限のうちいずれか一つの実行権限にて動作し、
    　信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、
    　第一の実行権限にて動作する第一の監視部は第二の実行権限にて動作する第二の監視部のソフトウェアを監視対象に含む、
    　監視装置。
  2. 　前記監視装置は、３以上の前記監視部を備え、
    　前記監視部は、それぞれ３種類の実行権限のうちいずれか一つの実行権限にて動作し、
    　信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、
    　第一の実行権限にて動作する第一の監視部は第二の実行権限にて動作する監視部のソフトウェアを監視対象に含み、
    　前記第一の監視部と前記第二の監視部のうち少なくとも１つは第三の実行権限にて動作する第三の監視部のソフトウェアを監視対象に含む、
    　請求項１に記載の監視装置。
  3. 　前記監視装置は、４以上の前記監視部を備え、
    　前記監視部は、それぞれ４種類の実行権限のうちいずれか一つの実行権限にて動作し、
    　信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、
    　第一の実行権限にて動作する第一の監視部は第二の実行権限にて動作する監視部のソフトウェアを監視対象に含み、
    　前記第一の監視部と前記第二の監視部のうち少なくとも１つは第三の実行権限にて動作する第三の監視部のソフトウェアを監視対象に含み、
    　前記第一の監視部と前記第二の監視部と前記第三の監視部のうち少なくとも１つは第四の実行権限にて動作する第四の監視部のソフトウェアを監視対象に含む、
    　請求項１に記載の監視装置。
  4. 　前記監視装置は、セキュアアプリと仮想ソフトウェア基盤と１以上の仮想マシン上にて動作し、
    　前記第一の実行権限は、セキュアアプリの実行権限、仮想ソフトウェア基盤の実行権限、仮想マシンのカーネル実行権限のうちの一つであり、前記第二の実行権限は、仮想ソフトウェア基盤の実行権限、仮想マシンのカーネル実行権限、仮想マシンのユーザ権限のうちの一つであり、前記第三の実行権限は、仮想マシンのカーネル実行権限、仮想マシンのユーザ権限うちの一つであり、前記第四の実行権限は、仮想マシンのユーザ権限である、
    　請求項３に記載の監視装置。
  5. 　前記監視装置は、仮想ソフトウェア基盤と２以上の仮想マシン上にて動作し、
    　前記仮想マシンに割り当てられた実行権限にて動作する監視部が２以上存在する場合、第一の仮想マシンの監視部は、第二の仮想マシンの監視部のソフトウェアを監視対象に含み、前記第一の仮想マシンと前記第二の仮想マシンは、攻撃者によって改ざんされる可能性に応じて分類される、
    　請求項１から４のいずれか１項に記載の監視装置。
  6. 　前記監視装置は、セキュアアプリと、ホストオペレーティングシステムと、１以上の仮想ソフトウェア基盤および１以上の仮想マシン上、または、１以上のコンテナ仮想化基盤および２以上のコンテナ上にて動作し、
    　前記第一の実行権限と、前記第二の実行権限と、前記第三の実行権限と、前記第四の実行権限は、セキュアアプリの実行権限と、ホストオペレーティングシステムの実行権限と、仮想ソフトウェア基盤の実行権限と、仮想マシンのカーネル実行権限と、仮想マシンのユーザ実行権限と、コンテナの実行権限のうちの一つであり、
    　同一の実行権限にて動作する仮想マシンの監視部が２以上存在する場合、第一の仮想マシンの監視部は、第二の仮想マシンの監視部のソフトウェアを監視対象に含み、
    　前記第一の仮想マシンと前記第二の仮想マシンは、攻撃者によって改ざんされる可能性に応じて分類され、
    　同一の実行権限にて動作するコンテナの監視部が２以上存在する場合、第一のコンテナの監視部は、第二のコンテナの監視部のソフトウェアを監視対象に含み、
    　前記第一のコンテナと前記第二のコンテナは、攻撃者によって改ざんされる可能性に応じて分類される、
    　請求項３に記載の監視装置。
  7. 　前記監視部は、所定の時間経過と、所定の外部ネットワーク接続時間経過と、システム起動と、システム再起動と、外部ネットワーク接続確立と、外部デバイス接続のうち少なくとも１つを含むイベントに応じて、前記監視対象を監視する、
    　請求項１から６のいずれか１項に記載の監視装置。
  8. 　前記監視装置は、車載システム上において動作し、
    　前記監視部は、所定の走行時間経過と、所定の停止時間経過と、所定の走行距離経過と、走行モードの切り替えと、給油または給電の終了と、車両診断の実施と、緊急アラートの発呼のうち少なくとも１つを含むイベントに応じて、前記監視対象を監視する、
    　請求項１から６のいずれか１項に記載の監視装置。
  9. 　前記監視部は、他の監視部の監視処理の実行回数、監視処理において異常と判定された回数と、監視処理において正常と判定された回数のうち少なくとも１つの回数に応じて、前記監視対象を監視する、
    　請求項１から６のいずれか１項に記載の監視装置。
  10. 　前記監視部は、前記監視対象がソフトウェアである場合、メモリまたはストレージに記憶されている前記監視対象であるソフトウェアのハッシュ値、マスク値、複製値のうち少なくとも１つの情報を取得値として取得し、事前に定義された期待値と取得値を比較し、一致する場合に正常と判定し、一致しない場合に異常と判定する、
    　請求項１から９のいずれか１項に記載の監視装置。
  11. 　前記ソフトウェアは仮想ソフトウェア基盤のプログラムと設定ファイル、仮想マシンのカーネルプログラムと設定ファイル、仮想マシン上のユーザアプリのプログラムと設定ファイル、前記監視部のプログラムと設定ファイルのうち少なくとも１つを含む、
    　請求項１０に記載の監視装置。
  12. 　前記監視部は、前記監視対象が通信ログである場合、通信ログを取得し、許可リストと、拒否リストと、正常時の統計情報のうち少なくとも１つを用いて通信ログを検証し、前記許可リストに含まれる場合に正常と判定し、含まれない場合に異常と判定し、前記拒否リストに含まれない場合に正常と判定し、含まれる場合に正常と判定し、前記正常時の統計情報から逸脱していない場合に正常と判定し、逸脱している場合に正常と判定する、
    　請求項１から１１のいずれか１項に記載の監視装置。
  13. 　前記通信ログは、イーサネットと、ＣＡＮプロトコルと、ＦｌｅｘＲａｙプロトコルと、ＳＯＭＥ／ＩＰプロトコルと、ＳＯＭＥ／ＩＰ－ＳＤプロトコルと、システムコールと、ハイパーコールのうち少なくとも一つを含む、
    　請求項１２に記載の監視装置。
  14. 　前記監視部は、前記監視対象ごとに設定された優先度に応じて、前記監視対象の監視頻度と、監視精度と、監視手段のうち少なくとも１つを変更する、
    　請求項１から１３のいずれか１項に記載の監視装置。
  15. 　前記優先度は、前記監視対象の実行権限と、前記監視部または前記監視が動作する仮想マシンが外部ネットワーク接続機能を有するか否かと、前記監視部または前記監視が動作する仮想マシンが車両制御機能を有するか否かのうち少なくとも１つに応じて設定される、
    　請求項１４に記載の監視装置。
  16. 　前記監視装置は、さらに、前記監視装置が動作するシステムの状態またはイベントに応じて、監視情報に含まれる優先度と、前記監視対象に含まれる監視担当と監視対象の組み合わせである監視構成のうち少なくとも１つを変更する管理部を含む、
    　請求項１から１５のいずれか１項に記載の監視装置。
  17. 　前記管理部は、外部ネットワーク接続中か否かと、外部ネットワーク接続確立イベントの発生と、監視マシンのシステム状態と、前記監視部の監視結果と、異常を検知した監視部の実行権限と、異常を検知したソフトウェアの実行権限と、異常を検知した通信ログの宛先または送信元のうち少なくとも１つに応じて、前記優先度を変更する、
    　請求項１６に記載の監視装置。
  18. 　前記監視装置は、車載システム上において動作し、
    　前記管理部は、車両の走行状態に応じて、車両の制御機能を有する仮想マシンで動作する監視対象の優先度を変更し、車両の走行状態は、停止中、手動運転中、高度運転支援中、自動運転中のうちいずれかである、
    　請求項１６に記載の監視装置。
  19. 　前記管理部は、監視構成の変更後であっても、信頼度の低い監視部のソフトウェアを少なくとも１つの信頼度の高い監視部から監視する監視の信頼チェーンを構築できるように、監視構成を変更する、
    　請求項１６に記載の監視装置。
  20. 　前記管理部は、外部ネットワーク接続中か否かと、外部ネットワーク接続確立イベントの発生と、仮想マシンのシステム状態と、前記監視部の監視結果と、異常を検知した監視部の実行権限と、異常を検知したソフトウェアの実行権限と、異常を検知した通信ログの宛先または送信元のうち少なくとも１つに応じて、監視構成を変更する、
    　請求項１６または１９に記載の監視装置。
  21. 　前記監視装置は、車載システム上において動作し、
    　前記管理部は、車両の走行状態に応じて、車両の制御機能を有する仮想マシンに関係する監視構成を変更し、車両の走行状態は、停止中、手動運転中、高度運転支援中、自動運転中のうちいずれかである、
    　請求項１６または１９に記載の監視装置。
  22. 　前記管理部は、予め定義された２以上の監視構成から一つを選択する手段と、監視部を頂点とし、監視担当を道の始点とし、監視対象を道の終点とする有向グラフとして前記監視構成を記憶し、所定のアルゴリズムで有向グラフを再構築する手段と、監視部をノードとし、監視担当を親ノードとし、監視対象を子ノードとするツリー構造として前記監視構成を記憶し、所定のアルゴリズムでツリー構造を再構築する手段のうち少なくとも１つの手段で監視構成を変更する、
    　請求項１６、１８から２１のいずれかの１項に記載の監視装置。
  23. 　前記監視装置は、さらに、監視サーバーへ監視結果を通知する監視サーバー通知部を備える、監視装置である、
    　請求項１に記載の監視装置。
  24. 　監視装置と監視サーバーで構成される監視システムであって、
    　前記監視装置は、ソフトウェアまたは通信ログを監視対象として監視する２以上の監視部と、
    　監視部識別子と、監視対象識別子と、正常判定時刻と、異常判定時刻と、のうち少なくとも２つを監視結果として前記監視サーバーへ送信する監視サーバー通信部と、
    　を備え、
    　前記監視サーバーは、前記監視結果を受信し、グラフィカルユーザーインターフェース上に前記監視結果を表示する監視結果表示部を備える、
    　監視システム。
  25. 　前記監視結果表示部は、システムアーキテクチャに関連付けて前記監視結果を表示し、異常を検知した監視部または異常が検知された監視対象を強調する手段と、所定のタイムラインに関連付けて監視結果を表示し、正常判定時刻または異常判定時刻を強調する手段のうち少なくとも１つの手段でグラフィカルユーザーインターフェース上に監視結果を表示する、
    　請求項２４に記載の監視システム。
  26. 　前記監視サーバーは、さらに、前記監視対象と、前記監視対象を監視する監視部と、前記監視対象の優先度と、前記優先度に対応した監視方法のうち少なくとも１つの監視情報の変更を受け付け、前記監視装置に前記変更を要求する監視情報変更部を備え、
    　前記監視装置は、前記監視情報変更部の要求に応じて前記監視情報を更新する監視情報更新部を備える、
    　請求項２５に記載の監視システム。
  27. 　ソフトウェアと通信ログのうち少なくとも１つを監視対象として監視する２以上の監視ステップであって、
    　前記監視ステップは、それぞれ２種類の実行権限のうちいずれか一つの実行権限にて実行され、
    　信頼度の低い監視ステップを実行するソフトウェアを少なくとも１つの信頼度の高い監視ステップにて監視できるように、
    　第一の実行権限にて実行される第一の監視ステップは第二の実行権限にて実行される第二の監視ステップを実行するソフトウェアを監視対象に含む、
    　監視方法。
PCT/JP2021/020677 2021-05-31 2021-05-31 監視装置、監視システムおよび監視方法 WO2022254519A1 (ja)

Priority Applications (7)

Application Number Priority Date Filing Date Title
PCT/JP2021/020677 WO2022254519A1 (ja) 2021-05-31 2021-05-31 監視装置、監視システムおよび監視方法
JP2022567193A JP7189397B1 (ja) 2021-05-31 2022-05-27 監視装置、監視システム及び監視方法
EP22815997.6A EP4350548A1 (en) 2021-05-31 2022-05-27 Monitoring device, monitoring system, and monitoring method
PCT/JP2022/021731 WO2022255247A1 (ja) 2021-05-31 2022-05-27 監視装置、監視システム及び監視方法
CN202280036869.4A CN117355832A (zh) 2021-05-31 2022-05-27 监视装置、监视系统及监视方法
JP2022176683A JP7253663B2 (ja) 2021-05-31 2022-11-02 監視装置、監視システム及び監視方法
US18/519,690 US20240086290A1 (en) 2021-05-31 2023-11-27 Monitoring device, monitoring system, and monitoring method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2021/020677 WO2022254519A1 (ja) 2021-05-31 2021-05-31 監視装置、監視システムおよび監視方法

Publications (1)

Publication Number Publication Date
WO2022254519A1 true WO2022254519A1 (ja) 2022-12-08

Family

ID=84323955

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/JP2021/020677 WO2022254519A1 (ja) 2021-05-31 2021-05-31 監視装置、監視システムおよび監視方法
PCT/JP2022/021731 WO2022255247A1 (ja) 2021-05-31 2022-05-27 監視装置、監視システム及び監視方法

Family Applications After (1)

Application Number Title Priority Date Filing Date
PCT/JP2022/021731 WO2022255247A1 (ja) 2021-05-31 2022-05-27 監視装置、監視システム及び監視方法

Country Status (5)

Country Link
US (1) US20240086290A1 (ja)
EP (1) EP4350548A1 (ja)
JP (2) JP7189397B1 (ja)
CN (1) CN117355832A (ja)
WO (2) WO2022254519A1 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022254519A1 (ja) * 2021-05-31 2022-12-08 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 監視装置、監視システムおよび監視方法
CN118103820A (zh) * 2022-09-27 2024-05-28 松下汽车电子系统株式会社 信息处理装置、信息处理装置的控制方法以及程序
WO2024070141A1 (ja) * 2022-09-27 2024-04-04 パナソニックオートモーティブシステムズ株式会社 情報処理装置、情報処理装置の制御方法及びプログラム

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019057167A (ja) * 2017-09-21 2019-04-11 大日本印刷株式会社 コンピュータプログラム、デバイス及び判定方法
WO2020004315A1 (ja) * 2018-06-27 2020-01-02 日本電信電話株式会社 異常検知装置、および、異常検知方法
WO2020026693A1 (ja) * 2018-07-30 2020-02-06 株式会社デンソー センター装置、表示装置、車両状態の特定結果表示システム、車両状態の特定結果送信プログラム及び車両状態の特定結果表示プログラム
WO2021014539A1 (ja) * 2019-07-22 2021-01-28 日本電気株式会社 セキュリティ管理装置、セキュリティ管理方法、及び非一時的なコンピュータ可読媒体

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019144785A (ja) 2018-02-20 2019-08-29 富士通株式会社 監視プログラム、監視装置及び監視方法
WO2022254519A1 (ja) * 2021-05-31 2022-12-08 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ 監視装置、監視システムおよび監視方法

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019057167A (ja) * 2017-09-21 2019-04-11 大日本印刷株式会社 コンピュータプログラム、デバイス及び判定方法
WO2020004315A1 (ja) * 2018-06-27 2020-01-02 日本電信電話株式会社 異常検知装置、および、異常検知方法
WO2020026693A1 (ja) * 2018-07-30 2020-02-06 株式会社デンソー センター装置、表示装置、車両状態の特定結果表示システム、車両状態の特定結果送信プログラム及び車両状態の特定結果表示プログラム
WO2021014539A1 (ja) * 2019-07-22 2021-01-28 日本電気株式会社 セキュリティ管理装置、セキュリティ管理方法、及び非一時的なコンピュータ可読媒体

Also Published As

Publication number Publication date
JPWO2022255247A1 (ja) 2022-12-08
US20240086290A1 (en) 2024-03-14
JP7189397B1 (ja) 2022-12-13
JP2023002832A (ja) 2023-01-10
EP4350548A1 (en) 2024-04-10
WO2022255247A1 (ja) 2022-12-08
CN117355832A (zh) 2024-01-05
JP7253663B2 (ja) 2023-04-06

Similar Documents

Publication Publication Date Title
JP7194396B2 (ja) セキュアロックダウンを実装するように構成された関連装置を有する特別にプログラムされたコンピューティングシステムおよびその使用方法
WO2022254519A1 (ja) 監視装置、監視システムおよび監視方法
US10380344B1 (en) Secure controller operation and malware prevention
US11509666B2 (en) Automated security policy generation for controllers
EP3699794A1 (en) System and method for detecting exploitation of a component connected to an in-vehicle network
CN109344609A (zh) 一种tcu模块、tcu系统及保护方法
CN112653655A (zh) 汽车安全通信控制方法、装置、计算机设备及存储介质
Hamad et al. Red-Zone: Towards an Intrusion Response Framework for Intra-vehicle System.
CN109992351A (zh) 虚拟主机程序安全控制方法、装置、设备和介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21944029

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 21944029

Country of ref document: EP

Kind code of ref document: A1