WO2020079928A1 - Dispositif de traitement d'informations, procédé de traitement d'informations et programme - Google Patents

Dispositif de traitement d'informations, procédé de traitement d'informations et programme Download PDF

Info

Publication number
WO2020079928A1
WO2020079928A1 PCT/JP2019/030795 JP2019030795W WO2020079928A1 WO 2020079928 A1 WO2020079928 A1 WO 2020079928A1 JP 2019030795 W JP2019030795 W JP 2019030795W WO 2020079928 A1 WO2020079928 A1 WO 2020079928A1
Authority
WO
WIPO (PCT)
Prior art keywords
vehicle
risk
function
information
incident
Prior art date
Application number
PCT/JP2019/030795
Other languages
English (en)
Japanese (ja)
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
Priority claimed from JP2019098725A external-priority patent/JP7344009B2/ja
Application filed by パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ filed Critical パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
Priority to CN201980067829.4A priority Critical patent/CN112867642B/zh
Priority to EP19874667.9A priority patent/EP3868617A4/fr
Publication of WO2020079928A1 publication Critical patent/WO2020079928A1/fr
Priority to US17/230,496 priority patent/US11790088B2/en

Links

Images

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/01—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles operating on vehicle systems or fittings, e.g. on doors, seats or windscreens
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R25/00—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles
    • B60R25/10—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles actuating a signalling device
    • B60R25/102—Fittings or systems for preventing or indicating unauthorised use or theft of vehicles actuating a signalling device a signal being sent to a remote location, e.g. a radio signal being transmitted to a police station, a security company or the owner
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]

Definitions

  • the present invention relates to an information processing device that processes information used in a vehicle.
  • Patent Document 1 A technology for improving the security of a highly functional automobile realized by information processing has been proposed (see Patent Document 1, for example).
  • the countermeasures disclosed in Patent Document 1 are to detect and respond to an attack that has occurred due to the transmission of an abnormal message or the like after the attacker has already entered the vehicle-mounted network. In other words, the vehicle is affected by the attack until the response is completed. In addition, when an attack is performed by a pattern unknown to the vehicle that is the attack target, it may take time to detect or stop the abnormality, or the damage may be serious.
  • the present invention provides an information processing device or the like that prevents intrusion into an in-vehicle network and prevents the occurrence of cyber attacks and the seriousness of damage, even if the method is unknown to the vehicle itself.
  • An information processing apparatus includes an incident information acquisition unit that acquires incident information regarding an incident of a cyber attack that has occurred in a vehicle, and a vehicle information acquisition unit that acquires first vehicle information regarding a state of a first vehicle.
  • a storage unit that stores the incident information and the first vehicle information, and a vehicle function of the first vehicle based on the degree of coincidence between the incident information and the first vehicle information stored in the storage unit.
  • a risk determination unit that determines a risk level, a risk countermeasure instruction generation unit that generates a function restriction instruction for the vehicle function when the risk level is higher than a first reference, and an instruction output unit that outputs the function restriction instruction.
  • the information processing apparatus acquires incident information regarding an incident of a cyber attack that has occurred in a vehicle, acquires first vehicle information regarding a state of a first vehicle, and the incident
  • the risk level of the vehicle function of the first vehicle is determined based on the degree of coincidence between the information and the first vehicle information, and when the risk level is higher than the first reference, a function restriction instruction for the vehicle function is generated. Then, the function restriction instruction is output.
  • a program is an information processing apparatus including a processor and a memory, and is executed by the processor using the memory, thereby causing the processor to generate an incident regarding a cyber attack incident that occurs in a vehicle.
  • Information is acquired, first vehicle information regarding the state of the first vehicle is acquired, and the risk level of the vehicle function of the first vehicle is determined based on the degree of coincidence between the incident information and the first vehicle information, When the risk level is higher than the first standard, a function restriction instruction for the vehicle function is generated and the function restriction instruction is output.
  • a recording medium such as a system, an integrated circuit, or a computer-readable CD-ROM
  • an apparatus, a system, a method, an integrated circuit, a computer program, or a recording medium May be realized in any combination.
  • the present invention provides an information processing device or the like that suppresses intrusion into an in-vehicle network and prevents occurrence of cyber attack or serious damage even if it is a method unknown to the vehicle itself.
  • FIG. 1 is a diagram showing an outline of a configuration example of a security risk countermeasure system including the information processing apparatus according to the first embodiment.
  • FIG. 2 is a diagram showing a data configuration example of incident information in the first embodiment.
  • FIG. 3 is a diagram showing a configuration example of an in-vehicle network included in a vehicle to which the security risk countermeasure by the above security risk countermeasure system is applied.
  • FIG. 4 is a diagram showing a configuration example of a security risk countermeasure server included in the above security risk countermeasure system.
  • FIG. 5 is a flowchart showing a procedure example of processing of security risk countermeasures executed by the security risk countermeasure server.
  • FIG. 6 is a sequence diagram showing a procedure in the security risk countermeasure process including cooperation between the incident information collecting server and the security risk countermeasure server.
  • FIG. 7A is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7B is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7C is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7D is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7E is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7F is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7A is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7B is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 7C is an example of a risk point table used in the above
  • FIG. 7G is an example of a risk point table used in the above security risk countermeasure processing.
  • FIG. 8 is a flowchart showing an example of the procedure of the above-mentioned risk point table update processing.
  • FIG. 9 is a sequence diagram showing a procedure including cooperation between the first vehicle and the security risk countermeasure server in the security risk countermeasure process.
  • FIG. 10 is a diagram showing a data configuration example of vehicle information in the first embodiment.
  • FIG. 11 is a diagram showing a data configuration example of vehicle information in the first embodiment.
  • FIG. 12 is a diagram showing a data configuration example of the risk level management list according to the first embodiment.
  • FIG. 13 is a flowchart showing an example of the procedure of the risk score calculation processing included in the risk level management list.
  • FIG. 14A is a flowchart showing an example of a procedure of a process of calculating risk points of an in-vehicle device of the first vehicle in the above security risk countermeasure process.
  • FIG. 14B is a flowchart showing an example of the procedure of the risk point calculation process of the traveling position of the first vehicle in the above security risk countermeasure process.
  • FIG. 14C is a flowchart showing an example of a procedure of a risk point calculation process of the vehicle type of the first vehicle in the above security risk countermeasure process.
  • FIG. 14D is a flowchart showing an example of the procedure of the risk point calculation process of the communication protocol of the first vehicle in the above security risk countermeasure process.
  • FIG. 14A is a flowchart showing an example of a procedure of a process of calculating risk points of an in-vehicle device of the first vehicle in the above security risk countermeasure process.
  • FIG. 14B is a flowchart showing an example of the procedure of the risk point calculation process of the traveling position of the first
  • FIG. 14E is a flowchart showing an example of the procedure of the risk point calculation process of the on-board function of the first vehicle in the above security risk countermeasure process.
  • FIG. 14F is a flowchart showing an example of a procedure of a process of calculating the risk points of the traveling state of the first vehicle in the process of the security risk countermeasure.
  • FIG. 15 is a flowchart showing an example of the procedure of the risk control process using the risk score included in the risk level management list.
  • FIG. 16A is a sequence diagram showing a procedure including cooperation between the first vehicle and the security risk countermeasure server in the processing of the security risk countermeasure described above.
  • FIG. 16B is a sequence diagram showing a procedure including cooperation between the first vehicle and the security risk countermeasure server in the processing of the security risk countermeasure described above.
  • FIG. 17 is a flowchart showing an example of the procedure of the risk control process using the risk score included in the risk level management list.
  • FIG. 18A is a flowchart showing a procedure example of risk control processing using the risk score included in the risk level management list.
  • FIG. 18B is a flowchart showing an example of the procedure of the risk control process using the risk score included in the risk level management list.
  • FIG. 18C is a flowchart showing an example of the procedure of the risk control process using the risk score included in the risk level management list.
  • FIG. 19 is a diagram showing an outline of a configuration example of a security risk countermeasure system including the information processing apparatus according to the second embodiment.
  • FIG. 19 is a diagram showing an outline of a configuration example of a security risk countermeasure system including the information processing apparatus according to the second embodiment.
  • FIG. 20 is a flowchart showing a procedure example of security risk countermeasure processing executed by the security risk countermeasure server realized by the information processing apparatus according to the second embodiment.
  • FIG. 21 is a sequence diagram showing a procedure in the process of the security risk countermeasure, which includes cooperation between the second vehicle and the security risk countermeasure server and cooperation between the first vehicle and the security risk countermeasure server.
  • FIG. 22 is a flowchart showing a procedure example of the risk control processing of the first vehicle using the risk score of the second vehicle.
  • FIG. 23 is a flowchart showing a procedure example of the risk control processing of the first vehicle using the risk score of the second vehicle.
  • FIG. 24A is a flowchart showing a procedure example of risk control processing of the first vehicle using the distance between the first vehicle and the second vehicle.
  • FIG. 24B is a flowchart showing a procedure example of the risk control processing of the first vehicle using the distance between the first vehicle and the second vehicle.
  • FIG. 25 is a flowchart showing an example of a procedure of security countermeasure processing according to the incident history of the second vehicle.
  • FIG. 26 is a diagram illustrating a configuration example of an in-vehicle information processing device that executes the security risk countermeasure according to the embodiment.
  • an information processing apparatus includes an incident information acquisition unit that acquires incident information regarding an incident of a cyber attack that has occurred in a vehicle, and a first information regarding a state of a first vehicle.
  • a vehicle information acquisition unit that acquires vehicle information, a storage unit that stores the incident information and the first vehicle information, and based on the degree of coincidence between the incident information and the first vehicle information stored in the storage unit.
  • a risk determination unit that determines a risk level of a vehicle function of the first vehicle; a risk measure instruction generation unit that generates a function restriction instruction for the vehicle function when the risk level is higher than a first reference;
  • An instruction output unit that outputs a limitation instruction.
  • the risk level of the first vehicle according to the state is determined based on the information on incidents of cyber attacks on many vehicles.
  • the risk level obtained as a result of this determination exceeds the predetermined standard and is high, by restricting the function of the first vehicle, it is possible to suppress the occurrence of an attack or the spread of adverse effects due to the attack.
  • the risk countermeasure instruction generation unit may generate a function invalidation instruction for the vehicle function as the function restriction instruction when the risk level is higher than the second standard above the first standard. Further, for example, when the risk level is lower than the first reference, a function restriction cancellation instruction generation unit that generates a function restriction cancellation instruction for the vehicle function is provided, and the instruction output unit outputs the function restriction cancellation instruction. Good.
  • the risk determination unit may redetermine the risk level of the vehicle function.
  • the function restriction release instruction generation unit releases the function restriction for the communication related function among the vehicle functions.
  • a function restriction release instruction may be generated.
  • the risk determination unit may redetermine the risk level of the vehicle function.
  • the size of the threat of cyber attacks can change depending on the location. With this configuration, appropriate function restrictions are applied according to the changing risk level of the vehicle or the necessary countermeasures.
  • the vehicle information acquisition unit acquires second vehicle information about the state of the second vehicle, the risk determination unit, the second vehicle information of the second vehicle based on the degree of coincidence of the incident information and the second vehicle information.
  • the risk level of the vehicle function is determined, and when the risk level of the vehicle function of the second vehicle is higher than a third standard, the risk countermeasure instruction generation unit, the risk countermeasure instruction generation unit of the first vehicle corresponding to the vehicle function of the second vehicle.
  • a function restriction instruction for the vehicle function may be generated.
  • the risk of a cyber attack of the own vehicle which exchanges information with the vehicles running in the vicinity, also increases. For example, fraudulent false information may be provided, or a message with malicious code embedded may be sent.
  • an appropriate level of function restriction is applied to the own vehicle in accordance with the changing risk level of the vehicle running nearby or the necessary countermeasure.
  • the distance between vehicles may be calculated from position information obtained from GPS (Global Positioning System) of each vehicle, or any method such as delay time of inter-vehicle communication, distance measured by radar, etc. You may calculate with.
  • the third criterion may be the same as or different from the first criterion or the second criterion which is compared with the risk level of the first vehicle.
  • the function restriction release instruction generation unit is configured to A function restriction release instruction for the vehicle function of the vehicle may be generated.
  • the risk level of the first vehicle information, among the accumulated incident information, when the new incident information matches the older incident information May be determined to be higher than the case where Further, for example, in the determination of the risk level of the vehicle function by the risk determination unit, the risk level of the first vehicle information, among the accumulated incident information, incident information that occurs a predetermined number or more in the latest predetermined period and When they match, it may be determined to be higher than when they match the incident information that has occurred less than a predetermined number of times in the predetermined period.
  • the information processing apparatus acquires incident information regarding an incident of a cyber attack that has occurred in a vehicle, acquires first vehicle information regarding a state of a first vehicle, and the incident
  • the risk level of the vehicle function of the first vehicle is determined based on the degree of coincidence between the information and the first vehicle information, and when the risk level is higher than the first reference, a function restriction instruction for the vehicle function is generated. Then, the function restriction instruction is output.
  • a program according to an aspect of the present invention is an information processing apparatus including a processor and a memory, and is executed by the processor using the memory, thereby causing the processor to generate an incident regarding a cyber attack incident that occurs in a vehicle.
  • first vehicle information regarding the state of the first vehicle is acquired, and the risk level of the vehicle function of the first vehicle is determined based on the degree of coincidence between the incident information and the first vehicle information,
  • the risk level is higher than the first standard, a function restriction instruction for the vehicle function is generated and the function restriction instruction is output.
  • the risk level of the first vehicle is determined according to the state of the vehicle, based on the information on incidents of cyber attacks on multiple vehicles. Further, when the risk level obtained as a result of the determination exceeds the predetermined standard and is high, by restricting the function of the first vehicle, it is possible to suppress the occurrence of an attack or the spread of adverse effects due to the attack.
  • a recording medium such as a system, an integrated circuit, or a computer-readable CD-ROM
  • an apparatus such as a system, an integrated circuit, or a computer-readable CD-ROM
  • an apparatus such as a system, an integrated circuit, or a computer-readable CD-ROM
  • an apparatus such as a system, an integrated circuit, or a computer-readable CD-ROM
  • an apparatus such as a system, an integrated circuit, or a computer-readable CD-ROM
  • a system, a method, an integrated circuit, a computer program, or a recording medium It may be realized by any combination of media.
  • Embodiment 1 In the security risk countermeasure system including the information processing apparatus according to the first embodiment, information on incidents of cyber attacks collected on a large number of vehicles (hereinafter, also referred to as incident information) and information on the current state of the vehicles ( Hereinafter, the possibility (risk level) of a cyber attack of the function of the vehicle (hereinafter, also referred to as the vehicle function) is determined by using the vehicle information.
  • Vehicle functions in the present embodiment are classified into communication-related functions and travel-related functions.
  • the communication-related functions are, for example, CAN communication, Wi-Fi (registered trademark) communication, Bluetooth (registered trademark) communication, and LTE communication functions.
  • the travel-related function is, for example, a function of automatic driving or various driving assistance.
  • a cyber attack is a threat that causes an abnormal operation.
  • the security risk countermeasure system 1 limits the vehicle function when the risk level of the vehicle function is higher than a predetermined standard. By limiting the vehicle function, it is possible to prevent unauthorized data from entering the vehicle-mounted network due to, for example, a cyber attack. Further, even if illegal data is sent to the vehicle-mounted network, the occurrence of abnormal operation due to this data can be suppressed.
  • FIG. 1 is a diagram showing an outline of a configuration example of a security risk countermeasure system 1 including an information processing apparatus according to this embodiment.
  • the security risk countermeasure server 10 the vehicle 20, and the incident information collection server 30 are connected via a communication network such as the Internet, and information can be exchanged with each other.
  • the incident information collection server 30 is, for example, an SOC (Security Operation Center) server provided by a vehicle manufacturer, and includes one or more information processing devices including a processor and a memory.
  • the incident information collection server 30 stores the history of incidents related to cyber attacks actually occurring in each vehicle as incident information.
  • FIG. 2 is a diagram showing a data configuration example of incident information according to the first embodiment. In the data configuration example shown in FIG. 2, the items included in the incident information are as follows.
  • Incident ID Character string for incident identification Date and time of occurrence: Date and time of occurrence of incident Area of occurrence: Area including the place where the incident occurred Vehicle type: Vehicle type of vehicle in which the incident occurred Risk parts: Parts targeted by the attack in the incident. In this example, the part is specified by the model number.
  • Risk function Vehicle function affected in the incident Entry route: Location on the in-vehicle network used for unauthorized access to the in-vehicle network or where unauthorized equipment is installed
  • Threat level Safety regarding the magnitude of the incident Evaluation according to a predetermined standard for. For example, those that do not affect the operation of in-vehicle devices are low. Those that affect acceleration / deceleration, steering, or perception of surrounding conditions by the driver or sensor are high. Others are medium.
  • the incident information may include items related to information other than the above.
  • the manufacturer or software version of the risk component the running state (running or stopped) of the vehicle when the incident occurred, information for identifying the vehicle in which the incident occurred, and the like may be included.
  • incident information is collected for many vehicles, it can be said that it is a large-scale data asset. Then, at least a part of the incident information is provided to the security risk countermeasure server 10 as needed. Incident information is provided from the incident information collection server 30 to the security risk countermeasure server 10 through, for example, a virtual private line (dotted line in FIG. 1), but is not limited to this.
  • incident information may be provided to the security risk countermeasure server 10 from the SOC incident information collection server of each vehicle manufacturer.
  • the incident information may be described in a format that conforms to, for example, STIX (Structured Threat Information Expression), which is an international standard for threat information, in order to facilitate sharing by such multiple subjects.
  • STIX Structured Threat Information Expression
  • the vehicle 20 is a vehicle for which the security risk countermeasure system 1 is currently executing the security risk countermeasure.
  • the vehicle for which the current security risk countermeasure is executed is also referred to as a first vehicle in order to distinguish it from the general vehicle or a specific other vehicle.
  • the vehicle 20 has an in-vehicle network 200.
  • FIG. 3 is a diagram showing a configuration example of the in-vehicle network 200.
  • the in-vehicle network 200 shown in FIG. 3 includes a plurality of sub-networks according to different communication protocols such as CAN (Controller Area Network), Ethernet (registered trademark), and FlexRay (registered trademark), and the ECU is one of these sub-networks. It is connected to the. Some of these ECUs are connected to, for example, a sensor (not shown) to collect data indicating the condition inside or around the vehicle, or connected to an actuator, and send a control signal to operate a device on the vehicle. Things are included. Further, as another example, an ECU that performs information processing regarding security such as monitoring data flowing through a network may be included.
  • CAN Controller Area Network
  • Ethernet registered trademark
  • FlexRay registered trademark
  • the vehicle function described above is realized by any of these ECUs or by cooperation involving data exchange between a plurality of ECUs.
  • Sub-networks having different communication protocols are connected via a gateway 220.
  • the gateway 220 converts data exchanged between sub-networks between communication protocols.
  • an in-vehicle infotainment (IVI) system 230 is connected to the in-vehicle network 200.
  • Each ECU and IVI system 230 are connected to an external communication network via a gateway 220 and an external communication device 240 having a function as a communication module.
  • the information regarding the occurrence of the incident, which is provided to the SOC, and the vehicle information, which is provided to the security risk countermeasure server 10, are also transmitted via this route from any of these ECUs.
  • the vehicle information will be described later with a specific example.
  • the security risk countermeasure server 10 uses the incident information acquired from the incident information collection server 30 and the vehicle information acquired from the vehicle 20 to determine the risk level related to the cyber attack of the vehicle function of the vehicle 20. Further, when the determined risk level is higher than a predetermined standard, the security risk countermeasure server 10 issues an instruction to limit the vehicle function of the vehicle 20 (hereinafter, also referred to as a function limitation instruction), and communicates this instruction. It transmits to the vehicle 20 via a network.
  • the security risk countermeasure server 10 is composed of one or more information processing devices including a processor and a memory.
  • FIG. 4 is a diagram showing a configuration example of the security risk countermeasure server 10.
  • the components of the security risk countermeasure server 10 include an incident information acquisition unit 11, a vehicle information acquisition unit 12, a storage unit 13, a risk determination unit 14, a risk point management unit 15, a risk countermeasure instruction generation unit 16, and an instruction output unit 17, Also, a function restriction release instruction generation unit 18 is included.
  • the incident information acquisition unit 11 receives and acquires incident information from the incident information collection server 30.
  • the vehicle information acquisition unit 12 receives and acquires vehicle information, which is information regarding the state of the vehicle 20.
  • the storage unit 13 stores the above-mentioned incident information, vehicle information, and other information used for determining a risk level described later.
  • the risk level management list and the risk point table described in FIG. 1 are also included in the other information accumulated in the accumulating unit 13, which will be described later using an example.
  • the risk determination unit 14 determines the risk level of various vehicle functions of the vehicle 20 based on the degree of coincidence between the incident information and the vehicle information of the vehicle 20.
  • the risk point management unit 15 manages risk point information, which is a kind of information used for the risk determination unit 14 to determine the risk level, based on the incident information.
  • the risk countermeasure instruction generation unit 16 generates an instruction (hereinafter, also referred to as a risk countermeasure instruction) regarding a restriction (including a case of invalidation) of a vehicle function as a risk countermeasure according to the risk level determined by the risk determination unit 14. To do.
  • the function restriction release instruction generation unit 18 generates an instruction to release the restriction on the vehicle function (hereinafter, also referred to as a function restriction release instruction) according to the risk level determined by the risk determination unit 14.
  • the instruction output unit 17 transmits a function restriction instruction and a function restriction cancellation instruction to the vehicle 20.
  • These components of the security risk countermeasure server 10 are functionally realized by the processor executing, for example, one or a plurality of programs stored in the memory in the information processing apparatus configuring the security risk countermeasure server 10.
  • the processing for security risk countermeasures executed by the security risk countermeasure system 1 is executed by the cooperation of these components of the security risk countermeasure server 10 while exhibiting the above-mentioned functions.
  • the incident information collection server 30 and the security risk countermeasure server 10 do not have to be individually established.
  • the incident information collecting server 30 and the security risk countermeasure server 10 may be an integrated system.
  • the incident information collecting server 30 may be a part of the security risk countermeasure server 10, and for example, the incident information collecting server 30 may function as the storage unit 13.
  • the function of the incident information acquisition unit 11 in this case may be to acquire incident information in a range used for processing from the storage unit 13.
  • FIG. 5 is a flowchart showing an example of the procedure of this processing executed by the security risk countermeasure server 10. In the following, for convenience of description, this procedure will be described by roughly dividing it into two stages.
  • step S1 and step S2 This is the first step of S2).
  • the other is to acquire vehicle information indicating the state of the first vehicle for which security risk countermeasures are executed, and based on the degree of agreement between the state of the first vehicle indicated by this vehicle information and the state of the vehicle indicated in the incident information. Then, the risk level of each vehicle function of the first vehicle is calculated from the risk points, and based on the calculated risk level, it is determined whether or not the restriction or removal of the restriction of the vehicle function is executed, and if necessary, the first This is the second stage until the risk countermeasure instruction for one vehicle is output (steps S3 to S7).
  • FIG. 6 is a sequence diagram showing a procedure including cooperation between the incident information collecting server 30 and the security risk countermeasure server 10, and relates to the first stage of the processing procedure example shown in FIG.
  • incident information is transmitted from the incident information collection server 30 to the security risk countermeasure server 10 (step S3010).
  • An example of the data structure of the incident information is shown in FIG. 2, and the description thereof will be omitted.
  • Transmission of incident information may be performed at regular time intervals, or may be triggered by the occurrence of a predetermined event such as when a predetermined number of records or records of incidents with a high threat level are added. . It may also be transmitted in response to a request from the security risk countermeasure server 10.
  • the incident information received by the incident information acquisition unit 11 is temporarily stored in the storage unit 13 (step S10).
  • the process up to this point corresponds to step S1 in the flowchart of FIG.
  • the risk point management unit 15 updates the risk point table based on this incident information (step S20).
  • Step S20 corresponds to step S2 in the flowchart of FIG.
  • the risk point table is a table that summarizes risk evaluation values (risk points) for cyber attacks in various states of the vehicle, and is stored in the storage unit 13.
  • the risk point is determined based on the incident record indicated by the incident information, and is updated when new incident information is acquired.
  • the risk point update process will be described later using an example.
  • 7A to 7G are examples of the risk point table according to the present embodiment.
  • the risk point table shown in FIG. 7A relates to the risk points by vehicle model, such as the equipment installed in the vehicle, in this example, the ECU and IVI system, by model number and software version.
  • the risk point table shown in FIG. 7B relates to risk points for each manufacturer (manufacturer) of a device mounted on the vehicle as a vehicle state.
  • the risk point table shown in FIG. 7C relates to risk points for each region in which the vehicle is traveling as the vehicle state.
  • the risk point table shown in FIG. 7D relates to risk points for each vehicle type as a vehicle state.
  • the risk point table shown in FIG. 7E relates to risk points for each communication protocol used in the vehicle-mounted network mounted on the vehicle as a vehicle state.
  • the risk point table shown in FIG. 7G relates to risk points for each traveling state for each vehicle function that is effective in the vehicle as a vehicle state.
  • the traveling state is classified into two traveling speed zones and a total of three states of stop.
  • risk points By determining risk points based on incident information, for example, the actual tendency of vulnerability to cyber attacks or the ease of being targeted by attackers by these states is reflected. A procedure of updating (or creating) a risk point table including such determination of risk points will be described below with reference to a flow chart.
  • FIG. 8 is a flowchart showing an example of a procedure of updating processing of each of the risk point tables described above by the risk point management unit 15. This process corresponds to step S2 in the flowchart of FIG. 5 and step S20 in the sequence diagram of FIG. The following description should be understood with reference to any of the risk point tables shown in FIGS. 7A to 7G and the incident information shown in FIG. 2 as appropriate.
  • the risk point management unit 15 first initializes the points in the risk point table (step S210), and sequentially with respect to the items indicating the types of states included in the risk point table, step S211 to step S218 described below. Are executed (table item loop in FIG. 8).
  • the item indicating the type of state is arranged to the left of the thick vertical ruled line of each risk point table.
  • the risk point table regarding the mounted devices in FIG. 7A “ECU-a” and “1. 0.1 "or the like.
  • “X”, “Y”, etc. are used.
  • step S211 the risk point management unit 15 determines whether or not one record of incident information includes information corresponding to the item indicating the type of the above state.
  • a predetermined value according to the threat level in the record is added as a risk point of this item (step S212).
  • the predetermined value according to such a threat level may be managed by a table (not shown) held in the storage unit 13, for example.
  • the risk point management unit 15 determines whether or not a predetermined time has already passed from the occurrence date and time contained in the record (step S213).
  • the predetermined value is subtracted from the risk points after the addition in step S212 (step S214). This is because adjustment of risk points is based on the fact that threats that are older than a certain degree are more likely to be threatened than they were at the time of occurrence, as a result of measures taken by manufacturers such as vehicles, ECUs, or communication devices. Is.
  • steps S211 to S214 in the table item loop are sequentially executed for the records included in the incident information (incident information loop in FIG. 8). That is, for example, for the vehicle type item “X” indicating the type of state, risk points corresponding to the threat levels of all records including “X” in the vehicle type field are added, and the number of records older than a certain degree is added to the number of records. Accordingly, the predetermined value is subtracted from the risk points. Note that steps S212 to S214 are omitted for the record that is No in step S211, and step S214 is omitted for the record that is No in step S213.
  • the risk point management unit 15 determines whether or not the number of records including the information corresponding to the item is equal to or larger than a predetermined reference value n (step S215). When the number of records is equal to or greater than the reference value n (Yes in step S215), the risk point management unit 15 adds a predetermined value to the risk points of this item (step S216). This is an adjustment of risk points based on the fact that it is highly likely that some incident-related factors such as vulnerabilities have occurred in many incident-related states.
  • the risk point management unit 15 determines whether or not the number of records including the information corresponding to the item is equal to or greater than a predetermined reference value m in a predetermined period going back from the present (step S217).
  • the risk point management unit 15 adds a predetermined value to the risk points of this item (step S218). This is an adjustment of the risk points based on the high likelihood of some tendency of the incident, such as unknown vulnerabilities for this item starting to be targeted by attackers.
  • the size of the risk point calculated in this way reflects the high level of risk based on the latest incident information acquired by the security risk countermeasure server 10 in various states of the vehicle against cyber attacks.
  • the risk point table updated in this way is used for determining the risk level of the first vehicle 20 executed in the next second stage.
  • FIG. 9 is a sequence diagram showing a procedure including cooperation between the first vehicle 20 and the security risk countermeasure server 10. In addition, this sequence diagram relates to the second stage of the processing procedure example shown in FIG.
  • Vehicle information is transmitted from the first vehicle 20 to the security risk countermeasure server 10 (step S3020).
  • the vehicle information is information about the state of the first vehicle 20, and is also referred to as first vehicle information below.
  • 10 and 11 are diagrams each showing an example of the data structure of the vehicle information.
  • the vehicle information in FIG. 10 includes information on devices included in the first vehicle 20, particularly devices related to information processing or communication, and is also referred to as a device list below.
  • vehicle information whose frequency of change is not high is, for example, daily processing such as the first start of each day of the first vehicle 20, or when a device configuration change occurs on the in-vehicle network 200.
  • the event may be transmitted to the security risk countermeasure server 10 with the specific event as a trigger.
  • the change of the device configuration here includes, for example, not only addition or deletion of a device but also software update.
  • the related function here is a vehicle function in which the information transmitted / received or other processed by each device is used in the first vehicle 20. In other words, it is a vehicle function that can be adversely affected if each device fails or is subjected to a cyber attack.
  • the example of the data configuration in FIG. 11 is an example of vehicle information regarding the latest various states of the first vehicle 20. Since the vehicle information in FIG. 11 includes information such as the traveling position and the traveling state that are frequently changed, for example, the state of the first vehicle 20 changes regularly or at a frequency of several minutes or less. It may be transmitted to the security risk countermeasure server 10 at any time.
  • the information items included in the vehicle information examples shown in FIGS. 10 and 11 are examples, and the present invention is not limited thereto.
  • it may be transmitted as one type of vehicle information including all items shown in FIGS. 10 and 11.
  • items for which the frequency of changes such as vehicle type, communication protocol, and installed functions are relatively low are security risks from the first vehicle 20 on a schedule different from other items for which the frequency of changes is high. It may be transmitted to the countermeasure server 10.
  • the information of all items may not be transmitted every time. For example, the vehicle ID for identifying the first vehicle 20 in the security risk countermeasure server 10 and the information of the item changed from the last transmission may be transmitted.
  • the item of the traveling position is not limited to the information expressed in the region such as the municipality in FIG. 11, and may include the information of the latitude and longitude acquired by the GPS receiver included in the first vehicle 20.
  • step S30 the vehicle information received by the vehicle information acquisition unit 12 is temporarily stored in the storage unit 13 (step S30).
  • the process up to this point corresponds to step S3 in the flowchart of FIG.
  • Step S40 corresponds to step S4 in the flowchart of FIG. The subsequent second stage will be described later.
  • the risk level management list is a list of risk levels (high risk) against cyber attacks determined for each vehicle function of the first vehicle 20, and is stored in the storage unit 13.
  • the risk level is represented by a risk score calculated using the risk point table based on the incident information and the vehicle information described above.
  • the risk level management list and the risk level calculation process will be described using an example.
  • FIG. 12 is a diagram showing a data configuration example of the risk level management list in the present embodiment.
  • the leftmost column shows the name of the vehicle function that the first vehicle 20 has.
  • the column on the right shows the type of each vehicle function. Further, the column on the right side shows the detailed contents of the restriction when each vehicle function is restricted in the security risk countermeasure system 1. Further, the column on the right further shows detailed contents when each vehicle function is invalidated in the security risk countermeasure system 1.
  • the contents of each column up to here are basically unchanged. However, if the vehicle function of the first vehicle 20 increases or decreases, the line relating to the vehicle function is added to or deleted from the list. Further, in the security risk countermeasure system 1, if there is a change in the operation rule regarding the restriction or invalidation of the vehicle function of the first vehicle 20, the contents of each column may be changed.
  • the risk level of each vehicle function determined by the risk determination unit 14 is represented by the risk score entered in the rightmost column in this example.
  • the procedure of the process of calculating the risk score input in this field will be described below with reference to a flow chart.
  • FIG. 13 is a flow chart showing an example of the procedure of risk score calculation processing by the risk determination unit 14. This process corresponds to step S4 in the flowchart of FIG. 5 and step S40 in the sequence diagram of FIG.
  • the following description should be understood by appropriately referring to the risk point table shown in FIGS. 7A to 7G, the vehicle information shown in FIGS. 10 and 11, and the risk level management list shown in FIG. 12. Further, in the following description, the risk determination unit 14 of the security risk countermeasure server 10 that has acquired the vehicle information illustrated in FIG. 11 indicates that the risk score for the vehicle function of “autonomous driving” in the traveling state column of this vehicle information. Is used as an example.
  • the risk determination unit 14 first initializes the risk score in the risk level management list (step S410). Next, when the risk determination unit 14 reads the device list of FIG. 10 that is the vehicle information stored in the storage unit 13 (step S411), steps S412 to S414 are performed, and the device whose model number is listed in the device list. Are sequentially executed (device loop in FIG. 12).
  • step S412 the risk determination unit 14 determines whether the vehicle function is associated with the device. This determination is performed based on the information on the related function of the device list shown in FIG. In this example in which the risk score for the vehicle function “automatic driving” is calculated, in step S412 for the model number “ECU-a”, it is determined that the vehicle function is associated with this device (Yes in step S412).
  • step S413 the risk determination unit 14 calculates risk points of this device (step S413).
  • FIG. 14A is an example of a procedure of a risk point calculation process of each device included in the first vehicle 20.
  • the risk determination unit 14 first initializes the risk points of the device included in the first vehicle 20, and then reads the model number of the device for which the risk points are calculated and the software version of the device from the device list (steps S4130, S4131, S4132).
  • the risk determination unit 14 refers to the risk point table of the device shown in FIG. 7A, and reads the risk points corresponding to the model number and software version read in steps S4131 and S4132 (step S4133).
  • the risk determination unit 14 that has read the model number “ECU-a” and the software version “1.0.2” at the head of the device list shown in FIG. 10 reads the risk point “2” from the risk point table of FIG. 7A.
  • the risk points read in step S4133 are added to the risk points of the device (step S4134).
  • the risk determination unit 14 reads the manufacturer of the device (step S4135), and reads the risk points corresponding to the read manufacturer with reference to the risk point table of the device manufacturer shown in FIG. 7B (step S4135). S4136).
  • the risk determination unit 14 that has read out the manufacturer “A company” at the head of the device list illustrated in FIG. 10 reads risk point “1” from the risk point table in step S4136.
  • the risk determination unit 14 outputs this risk point as a risk point of the device (step S4138), and ends the calculation of the risk point of the device.
  • step S4138 The risk point output in step S4138 is added to the vehicle function for which the current risk score is calculated, that is, the risk score of “autonomous driving” in this example (step S414).
  • step S414 the process of the risk determination unit 14 returns to step S412 in the flowchart of FIG. 13, and the vehicle function “automatic driving” indicates that the next device in the device list of FIG. Move on to the determination of whether it is related to.
  • the risk determination unit 14 executes the device loop for all the devices included in the device list.
  • the size of the risk point of the device included in the first vehicle 20 calculated in this way includes the risk of the in-vehicle device based on the incident information of the cyber attack including the ones that occurred in the vehicles other than the first vehicle 20. Is reflected.
  • the risk determination unit 14 uses the vehicle information shown in FIG. 11 to determine the magnitude of the risk of cyber attack regarding the state of the first vehicle 20 other than the device.
  • step S415 a risk point indicating the magnitude of the risk regarding the traveling position as the state of the first vehicle 20 is calculated.
  • FIG. 14B is an example of a procedure of a risk point calculation process of the traveling position of the first vehicle 20.
  • the risk determination unit 14 first initializes the risk point of the traveling position, and then reads the traveling position of the first vehicle 20, which is the risk point calculation target, from the vehicle information of FIG. 11 (steps S4150, S4151).
  • the risk determination unit 14 refers to the risk point table of the traveling position shown in FIG. 7C to read the risk points corresponding to the traveling position read in step S4151 (step S4152).
  • the risk determination unit 14 that has read the traveling position “Tokyo ward” in the vehicle information illustrated in FIG. 11 reads the risk point “2” from the risk point table of FIG. 7C.
  • the risk points read in step S4152 are added to the risk points of the traveling position initialized in step S4150 and output (steps S4153, S4154). This completes the calculation of the risk points for the traveling position.
  • the risk points output in step S4154 are added to the vehicle function for which the current risk score is calculated, that is, in this example, the risk score of “autonomous driving” after step S414 (step S416).
  • step S417 risk points indicating the magnitude of risk for the vehicle type as the state of the first vehicle 20 are calculated.
  • FIG. 14C is an example of a procedure of a risk point calculation process of the vehicle type of the first vehicle 20.
  • the risk determination unit 14 first initializes the risk points of the vehicle type, and then reads the vehicle type of the first vehicle 20 for which the risk points are calculated from the vehicle information of FIG. 11 (steps S4170, S4171).
  • the risk determination unit 14 reads the risk points corresponding to the vehicle type read in step S4171 by referring to the vehicle type risk point table shown in FIG. 7D (step S4172).
  • the risk determination unit 14 that has read the vehicle type “X” in the vehicle information shown in FIG. 11 reads the risk point “1” from the risk point table of FIG. 7D.
  • the risk points read in step S4172 are added to the risk points of the vehicle type initialized in step S4170 and output (steps S4173, S4174). This completes the calculation of the risk points for the vehicle type.
  • the risk points output in step S4174 are added to the vehicle function for which the current risk score is calculated, that is, in this example, the risk score of “autonomous driving” after step S416 (step S418).
  • step S419 risk points indicating the magnitude of risk regarding the communication protocol used as the state of the first vehicle 20 are calculated.
  • FIG. 14D is an example of a procedure of a risk point calculation process of the communication protocol used in the first vehicle 20.
  • the risk determination unit 14 first initializes the risk points of the communication protocol, and then reads the communication protocol used in the first vehicle 20, which is the risk point calculation target, from the vehicle information of FIG. 11 (steps S4190, S4191). .
  • the risk determination unit 14 refers to the risk point table of the intrusion route shown in FIG. 7E and reads the risk point corresponding to the communication protocol read in step S4191 (step S4192).
  • the risk determination unit 14 that has read out the communication protocols “CAN”, “FlexRay” and “MOST” in the vehicle information shown in FIG. 11 is associated with each communication protocol from the risk point table of FIG. 7E. Read the risk points “8”, “1”, and “2”.
  • the risk points read in step S4192 are added to the risk points of the communication protocol initialized in step S4170 and output (steps S4193, S4194). This completes the calculation of risk points for the communication protocol.
  • the risk points output in step S4194 are added to the vehicle function for which the current risk score is calculated, that is, in this example, the risk score of “autonomous driving” after step S418 (step S420).
  • step S421 risk points indicating the magnitude of the risk of the vehicle function (indicated as the mounted function in each figure) mounted as the state of the first vehicle 20 are calculated.
  • FIG. 14E is an example of a procedure of a risk point calculation process of a vehicle function installed in the first vehicle 20.
  • the risk determination unit 14 first initializes the risk points of the vehicle functions to be installed, and then reads the vehicle functions installed in the first vehicle 20 that is the risk point calculation target from the vehicle information of FIG. 11 (steps S4210 and S4211). ).
  • the risk determination unit 14 refers to the risk point table of the mounted vehicle functions shown in FIG. 7F and reads the risk points corresponding to the mounted vehicle functions read in step S4211 (step S4212).
  • the risk determination unit 14 that has read out the vehicle functions “driving support”, “autonomous driving”, and “Wi-Fi” that are included in the vehicle information shown in FIG. 11 reads each function from the risk point table of FIG. 7F.
  • the risk points “20”, “5”, and “10” associated with the name are read.
  • the risk points read in step S4212 are added to the risk points of the mounted vehicle function initialized in step S4210 and output (steps S4213 and S4214). With the above, the calculation of the risk points for the function of the mounted vehicle is completed.
  • the risk point output in step S4214 is added to the vehicle function for which the current risk score is calculated, that is, in this example, the risk score of “autonomous driving” after step S420 (step S422).
  • step S423 risk points indicating the magnitude of risk regarding the traveling state as the state of the first vehicle 20 are calculated.
  • FIG. 14F is an example of a procedure of a risk point calculation process of the traveling state of the first vehicle 20.
  • the risk determination unit 14 first initializes the risk points of the running state, and then reads the running state of the first vehicle 20 that is the risk point calculation target from the vehicle information of FIG. 11 (steps S4230 and S4231).
  • the risk determination unit 14 refers to the risk point table of the running state shown in FIG. 7G and reads the risk points corresponding to the running state read in step S4231 (step S4232).
  • the risk determination unit 14 that has read the driving states “automatic driving” and “stop” from the vehicle information illustrated in FIG. 11 corresponds to “stop” under the function name “automatic driving” from the risk point table of FIG. 7G.
  • the risk points read in step S4232 are added to the running-state risk points initialized in step S4230 and output (steps S4233, S4234). With the above, the calculation of the risk points regarding the traveling state is completed.
  • the risk point output in step S4234 is added to the vehicle function for which the current risk score is calculated, that is, in this example, the risk score of “autonomous driving” after step S422 (step S424).
  • risk points for various items related to the state of the first vehicle 20 are calculated, and the total is automatically calculated. It is calculated as a driving risk score.
  • the risk determination unit 14 once writes the risk score calculated in this way into the field of the risk score for automatic driving in the risk level management list shown in FIG. 12 (step S425). This creates a risk level management list.
  • the security risk countermeasure server 10 collects a large number of vehicles including vehicles other than the first vehicle, which is the target of the current security risk countermeasures, and the state of each vehicle at the time of occurrence and the actual occurrence. Incident information indicating the degree of threat of the cyber attack that was performed is acquired. Then, based on this incident information, risk points for various states of the vehicle at the time of occurrence of a cyber attack are digitized and acquired according to the number of occurrences, the time of occurrence, the degree of threat, and the like.
  • the security risk countermeasure server 10 the risk of the state of the vehicle indicated by the vehicle information acquired from the first vehicle that matches the state of the vehicle at the time of the cyber attack indicated by the incident information described above. Points are accumulated and calculated as a risk score. That is, the higher the degree of coincidence between the state of the first vehicle indicated by the vehicle information and the state indicated by the incident information, the higher the risk score. Also, the risk score will be higher if the state of the first vehicle matches the state of the vehicle at the time of a more recent, more frequent, or more threatening cyber attack.
  • Such link score indicates the degree of risk (risk level) that the first vehicle, which is in the state indicated by the vehicle information, is likely to be attacked by a cyber attack. Further, the latest incident information acquired by the security risk countermeasure server 10 is used for quantifying the risk points, and for example, a case of a cyber attack that has not occurred in the first vehicle or the tendency thereof can be reflected. Therefore, not only a known cyber attack for the vehicle alone, but also a risk level for an unknown one is shown.
  • FIG. 15 is a flowchart showing an example of the procedure of the risk control processing executed by the security risk countermeasure server 10 using the risk score included in the risk level management list. The second example of the processing procedure shown in FIG. Regarding some of the stages.
  • the risk determination unit 14 reads the risk score of the currently effective vehicle function included in the risk level management list (step S500). This step corresponds to step S5 in the flowchart of FIG. 5 and step S50 in the sequence diagram of FIG.
  • the first threshold is a reference indicating a risk level for determining whether to limit the vehicle function.
  • the second threshold is a value of a risk score that is higher than the first threshold, and is a criterion indicating a higher risk level for determining whether or not to invalidate the vehicle function.
  • the first threshold is an example of the first standard in the present embodiment, and the second threshold is an example of the second standard.
  • the risk determination unit 14 determines whether the risk score read in step S500 is equal to or higher than the second threshold value (step S600). When the risk score is less than the second threshold value (No in step S600), the risk determination unit 14 further determines whether the risk score is equal to or higher than the first threshold value (step S601). Steps S600 and S601 correspond to step S6 of the flowchart of FIG. 5 and step S60 of the sequence diagram of FIG.
  • the vehicle function is not limited or invalidated, and the risk control process ends.
  • the risk determination unit 14 causes the risk countermeasure instruction generation unit 16 to generate an instruction to invalidate the vehicle function (hereinafter, also referred to as a function invalidation instruction). .
  • the risk countermeasure instruction generation unit 16 generates a function invalidation instruction in accordance with the content of the "invalidation" column of the risk control target vehicle function in the risk level management list (step S610).
  • the generated function invalidation instruction is output from the instruction output unit 17 (step S620) and transmitted to the first vehicle 20.
  • the risk determination unit 14 instructs the risk countermeasure instruction generation unit 16 to limit the vehicle function (hereinafter, also referred to as function limitation instruction). Is generated.
  • the risk countermeasure instruction generation unit 16 generates a function restriction instruction according to the content of the “restriction” column of the risk control target vehicle function in the risk level management list (step S611).
  • the generated function restriction instruction is output from the instruction output unit 17 (step S620) and transmitted to the first vehicle 20.
  • Steps S610 and S611 correspond to step S61 in the sequence diagram of FIG.
  • step S620 corresponds to step S62 in the sequence diagram of FIG.
  • the risk function calculated in the first step that is, the vehicle function restriction according to the risk level is executed by the processing whose example procedure is shown in the flowchart of FIG. If there is a high possibility that a valid vehicle function will be attacked by a cyber attack, by limiting this vehicle function, an attacker can intrude into the in-vehicle network, send out illegal data, or even send out illegal data. Occurrence or expansion can be suppressed.
  • the traveling position and the traveling state in the vehicle information shown in FIG. 11 may change relatively frequently.
  • the security risk countermeasure server 10 may correct the risk score only for these points (re-determination of the risk level).
  • a processing procedure for adding a change to the restriction on the vehicle function will be described using two examples of a case where the traveling position has changed and a case where the traveling state has changed.
  • FIGS. 16A and 16B are sequence diagrams showing a procedure including cooperation between the first vehicle 20 and the security risk countermeasure server 10. Further, each sequence diagram shows a modification of the procedure shown in the sequence diagram of FIG. 9, and common steps are denoted by common reference numerals. Hereinafter, the difference between the procedure shown in each figure and the procedure shown in FIG. 9 will be mainly described.
  • the traveling position change notification is, for example, a notification that is transmitted to the security risk countermeasure server 10 when the first vehicle 20 crosses a boundary between regions and indicates a new current traveling position. Note that this notification may be performed by transmitting only the items of the vehicle ID and the traveling position, which are part of the vehicle information shown in FIG. 11.
  • the risk determination unit 14 uses steps S415, S416, and S415 in the procedure of the flowchart shown in FIG. S425 is performed (step S40A), and then the second stage process is executed.
  • the procedure of FIG. 16B differs from the procedure shown in the sequence diagram of FIG. 9 in that the first vehicle 20 transmits a traveling state change notification instead of the first vehicle information shown in FIGS. 10 and 11. .
  • the traveling state change notification indicates, for example, a new current traveling speed zone that is transmitted to the security risk countermeasure server 10 when the traveling state of the first vehicle 20 changes from low speed traveling to high speed traveling at a predetermined speed or higher. It is a notification. It should be noted that this notification may be performed by transmitting only the vehicle ID and the traveling state item, which is a part of the vehicle information shown in FIG. 11.
  • the risk determination unit 14 executes steps S423 to S425 in the procedure of the flowchart shown in FIG. (Step S40B), and then the second stage process is executed.
  • FIG. 17 is a flowchart showing an example of the procedure of the risk control processing executed by the security risk countermeasure server 10 using the risk score included in the risk level management list, and the second example of the processing procedure shown in FIG. Regarding some of the stages.
  • This procedure is executed, for example, after the risk countermeasure instruction is once output by the processing whose example procedure is shown in the flowchart of FIG. 15, new first vehicle information from the first vehicle 20 is received, and the risk level is increased.
  • the management list is recreated (updated), and can be executed in the risk control loop from the second time onward in the flow chart of FIG.
  • this procedure may be executed when the above-mentioned traveling position change notification or traveling state change notification is received from the first vehicle 20, or when the risk point table is updated.
  • the risk determination unit 14 determines whether the risk score newly read from the risk level management list is less than the first threshold value (step S700). When the risk score is less than the first threshold value (Yes in step S700), the risk determination unit 14 determines whether or not the function invalidation instruction has not been issued (step S701). When the function disabling instruction has not been issued (Yes in step S701), the risk determination unit 14 issues a function restriction cancellation instruction (hereinafter, also referred to as a function restriction cancellation instruction) to the function restriction cancellation instruction generation unit. 18 to generate.
  • the function restriction release instruction generation unit 18 generates a function restriction release instruction (step S710), and the generated function restriction release instruction is output from the instruction output unit 17 (step S720) and transmitted to the first vehicle 20. Steps S700 and S701 correspond to step S7 in the flowchart of FIG.
  • the function restriction is not released. This is a measure for more reliably protecting the first vehicle 20 from a cyber attack in consideration that the vehicle function is invalidated when the risk level is very high.
  • the disabling of the vehicle function may be released, for example, after safety is confirmed by the vehicle manufacturer or SOC of the first vehicle 20.
  • FIG. 18A is a flowchart showing an example of a procedure of cancellation processing of the restriction of the vehicle function executed after recalculation of the risk score.
  • step S300A after the travel position change notification is acquired by the security risk countermeasure server 10 (step S300A) and stored in the storage unit 13, the risk determination unit 14 recalculates the risk score regarding the travel position (see FIG. 13).
  • steps S415 and S416 are executed) (step S400A) and written in the risk level management list.
  • the risk determination unit 14 newly reads the recalculated risk score from the risk level management list, and the subsequent steps are common to the processing procedure shown in FIG.
  • the same processing procedure as when the traveling position changes may be executed (see FIG. 18B).
  • the difference between the processing procedure shown in FIG. 18B and the processing procedure shown in FIG. 18A is that the security risk countermeasure server 10 obtains a traveling state change notification (step S300B), and the risk determination unit 14 relates to the traveling state.
  • the step of recalculating the risk score corresponds to steps S423 and S424 in the procedure of the flowchart shown in FIG.
  • FIG. 18C shows an example of a processing procedure for releasing the function restriction of the communication-related function when the traveling state changes to stop based on such an idea.
  • the risk determination unit 14 recalculates the risk score as shown in FIG. 18A. Instead, it is determined whether the traveling state has changed to stop (step S700C). When the traveling state changes to stop (Yes in step S700C), the risk determination unit 14 determines whether or not the function disabling instruction has been issued (step S701). When the function invalidation instruction has not been issued (Yes in step S701), the risk determination unit 14 causes the function limitation cancellation instruction generation unit 18 to generate the function limitation cancellation instruction for the communication related function.
  • the function restriction release instruction generation unit 18 generates a function restriction release instruction for the communication related function (step S710C), and the generated function restriction release instruction for the communication related function is output from the instruction output unit 17 (step S720C). It is transmitted to the first vehicle 20.
  • the second stage described so far is repeatedly executed (risk control loop in FIG. 5).
  • risk control loop in FIG. 5 it is possible to continuously apply the security risk countermeasure suitable for the risk level of the vehicle function that changes according to the vehicle state to the first vehicle 20 that is the target of the security risk countermeasure.
  • Embodiment 2 In the security risk countermeasure system including the information processing apparatus according to the second embodiment, a large number of vehicles are collected to determine the risk level of the vehicle function of the first vehicle, which is the vehicle currently subject to the security risk countermeasures. The point that the incident information of the obtained cyber attack is used is common to the first embodiment.
  • the second embodiment is different from the first embodiment in that, in addition to the incident information, the vehicle information of the vehicle other than the first vehicle (hereinafter, also referred to as the second vehicle) is used for the determination of the risk level.
  • the present embodiment will be described focusing on the differences from the first embodiment. Note that the description of the points in common with the first embodiment will be simplified or omitted.
  • the second vehicle here is, for example, a vehicle that can communicate with the first vehicle. More specifically, for example, it is a vehicle that is in the vicinity of the first vehicle and that can directly communicate with the first vehicle. In addition, for example, it is a vehicle that can establish communication with the first vehicle by being mediated by a relay station, a roadside machine, or another vehicle to which each is connected.
  • a relay station a roadside machine
  • the risk level of the first vehicle that exchanges information with the second vehicle also increases.
  • the second vehicle is the same ECU as the first vehicle and is equipped with an ECU (hereinafter, also referred to as risk ECU) having a risk point of a predetermined size or more, a vehicle of the same vehicle type, or The vehicle may have a common vehicle function.
  • the risk level of such a second vehicle against a cyber attack is high, the first vehicle is also likely to have a common vulnerability, and thus the risk level against a cyber attack is also high.
  • the second vehicle may be a vehicle that travels near the first vehicle regardless of whether or not there is communication with the first vehicle. If the second vehicle is subjected to a regional cyber attack, the first vehicle running nearby may also be exposed to the cyber attack, and the risk level is high. Therefore, limiting the vehicle function of the first vehicle according to the risk level other than the first vehicle in this way is also effective as a security risk countermeasure for the first vehicle.
  • FIG. 19 is a diagram showing an outline of a configuration example of a security risk countermeasure system 1A including the information processing device according to the present embodiment.
  • the security risk countermeasure server 10A, the vehicle 20A that is the first vehicle, and the incident information collection server 30 are connected via a communication network such as the Internet and can exchange information with each other.
  • the second vehicle 20B, which is different from the first vehicle 20A, is also connected to the security risk countermeasure server 10A and the incident information collection server 30 via a communication network such as the Internet, and can exchange information with each other.
  • the incident information collecting server 30 may have the same configuration as that of the first embodiment, and thus detailed description thereof will be omitted. Further, the configuration of incident information provided from the incident information collection server 30 to the security risk countermeasure server 10A may be the same as that of the first embodiment, and therefore detailed description thereof will be omitted.
  • the configuration of the in-vehicle networks 200A and 200B respectively provided is the same as the configuration of the in-vehicle network 200 of the first vehicle 20 in the first embodiment described with reference to FIG. It is common and detailed description is omitted.
  • the security risk countermeasure server 10A has the same basic configuration as the security risk countermeasure server 10 of the first embodiment.
  • the security risk countermeasure server 10A is also an example of the information processing apparatus of the present invention in this embodiment, which is configured by one or more information processing apparatuses including a processor and a memory.
  • the difference between the security risk countermeasure server 10A and the security risk countermeasure server 10 is the incident information acquired from the incident information collecting server 30 and the information on the state of the second vehicle acquired from the second vehicle 20B. Then, the second stage processing of determining the risk level related to the cyber attack of the vehicle function of the first vehicle 20A is performed.
  • this process can be executed together with the process using the first vehicle information acquired from the vehicle 20 to which the security risk countermeasure is executed in the first embodiment, and each component that executes the process. May be common to the constituent elements of the security risk countermeasure server 10, and thus detailed description thereof will be omitted.
  • FIG. 20 is a flowchart showing an example of the procedure of this processing executed by the security risk countermeasure server 10.
  • the processing procedure of updating the risk point table by the risk point management unit 15 (step S22) based on the accumulated incident information acquired from the incident information collection server 30 (step S21) and the acquired incident information is shown in FIG.
  • the description may be omitted because it may be common to the first embodiment.
  • the following procedure will be described with reference to the sequence diagram of FIG. 21 corresponding to the sequence diagram of FIG. 9 for comparison with the first embodiment.
  • the second vehicle 20B which is a vehicle other than the first vehicle 20A for which the security risk countermeasure is executed, is involved in the security risk countermeasure process of the first vehicle 20A.
  • the information about the state of the second vehicle 20B (hereinafter, also referred to as second vehicle information) transmitted from the second vehicle 20B is temporarily stored in the storage unit 13 by the vehicle information acquisition unit 12. (Step S23 of FIG. 20, Steps S22030 and S230 of FIG. 21).
  • the risk determination unit 14 determines the risk level of the second vehicle using the risk point table and the second vehicle information, and creates the risk level management list (including the case of updating) ( Step S24 in FIG. 20 and step S240 in FIG. 21).
  • the processing procedure for determining the risk level of the second vehicle and creating the risk level management list may be the same as the processing procedure for the first vehicle 20 described in the first embodiment with reference to FIGS. 10 to 14F. The description is omitted here.
  • the risk determination unit 14 which has once written the risk score of the second vehicle 20B into the risk level management list, then reads this risk score (step S25 of FIG. 20, step S250 of FIG. 21) risk control processing of the first vehicle 20A. That is, it is used for the determination (step S26 in FIG. 20) of whether or not the function restriction (including the case of invalidation) of the effective vehicle function is necessary.
  • FIG. 22 is a flowchart showing an example of a procedure of risk control processing of the first vehicle 20A using the risk score of the second vehicle 20B, which is executed in the security risk countermeasure server 10A.
  • the basic flow of the risk control processing of the first vehicle 20A in the present embodiment may be the same as the risk control processing in the first embodiment described using FIG.
  • the first threshold value, the second threshold value, the function invalidation instruction, the function restriction instruction, and the risk countermeasure instruction in the figure may be the same as those in the first embodiment, and thus the description thereof is omitted.
  • step S2500 When the risk determination unit 14 reads the risk score of the second vehicle 20B from the risk level management list (step S2500), it determines whether this risk score is equal to or higher than the second threshold value (step S2600). When the risk score of the second vehicle 20B is less than the second threshold value (No in step S2600), the risk determination unit 14 further determines whether this risk score is equal to or higher than the first threshold value (step S2601). Steps S2600 and S2601 correspond to step S26 in the flowchart of FIG. 20 and step S260 in the sequence diagram of FIG.
  • the risk score of the second vehicle 20B is less than the first threshold value (No in step S2601), the vehicle function of the first vehicle 20A is not limited or invalidated, and the risk control process ends.
  • the risk determination unit 14 causes the risk countermeasure instruction generation unit 16 to generate a function invalidation instruction for the vehicle function of the first vehicle 20A.
  • the risk countermeasure instruction generation unit 16 generates a function invalidation instruction in accordance with the content of the “invalidation” column of the risk control target vehicle function in the risk level management list (FIG. 12) (step S2610).
  • the generated function disabling instruction is output from the instruction output unit 17 (step S2620) and transmitted to the first vehicle 20A.
  • the risk determination unit 14 causes the risk countermeasure instruction generation unit 16 to generate a function restriction instruction.
  • the risk countermeasure instruction generation unit 16 generates a function restriction instruction according to the content of the “restriction” column of the risk control target vehicle function in the risk level management list (step S2611).
  • the generated function restriction instruction is output from the instruction output unit 17 (step S2620) and transmitted to the first vehicle 20A. Steps S2610 and S2611 correspond to step S261 in the sequence diagram of FIG. Further, step S2620 corresponds to step S262 in the sequence diagram of FIG.
  • the vehicle function of the first vehicle 20A is restricted according to the risk score of the second vehicle 20B, that is, the risk level by the processing whose example procedure is shown in the flowchart of FIG.
  • the vehicle function of the first vehicle 20A is not limited to the second vehicle 20B. It is possible to prevent the influence of incidents that occur in (1) from affecting via communication.
  • the selection of the second vehicle 20B for the first vehicle 20A may be performed at any time before the step S26 in the sequence diagram of FIG. 21, for example, by the risk determination unit 14 or the risk countermeasure instruction generation unit 16.
  • the steps up to step S24 are executed for all vehicles to be monitored by the security risk countermeasure system 1A.
  • the risk determination unit 14 includes information on the traveling position included in the vehicle information of the first vehicle 20A, which is one of the monitoring targets, and information about the traveling position included in the vehicle information of the monitored vehicles other than the first vehicle 20A.
  • the vehicle in a predetermined proximity (equal to or less than a predetermined distance) with the first vehicle 20A may be selected as the second vehicle 20B by using, and step S20B and subsequent steps may be executed.
  • a vehicle that has a predetermined proximity (equal to or less than a predetermined distance) with the first vehicle 20A and that has a function of communicating with the first vehicle 20A may be selected as the second vehicle 20B.
  • a vehicle including a device common to the first vehicle 20A may be selected as the second vehicle 20B.
  • the vehicle to which some function restriction is applied is the second.
  • the first vehicle 20A may be selected as the vehicle 20B, and the first vehicle 20A may be selected based on the traveling position, the function, the device, or the like provided as described above.
  • the first threshold and the second threshold that are compared with the risk score of the second vehicle 20B may be the same as the first threshold and the second threshold used in the first vehicle 20 in the first embodiment. Alternatively, it may be a criterion indicating a risk level different from these. It is sufficient that the fourth criterion is higher than the third criterion between the criterion (third criterion) indicated by the first threshold and the criterion (fourth criterion) indicated by the second threshold used in the second vehicle 20B.
  • the restriction applied to the first vehicle 20A when the risk score of the second vehicle 20B is less than the second threshold and equal to or more than the first threshold is that the risk score of the first vehicle 20A is less than the second threshold and the risk score of the own vehicle is less than the second threshold.
  • the limit may be different from the limit applied when the threshold value is equal to or more than one threshold value.
  • these restrictions may be defined by having two columns of “limit” columns in the risk level management list and dividing each column.
  • the vehicle function that is restricted or invalidated by the first vehicle 20A is the vehicle function of the first vehicle 20A that corresponds to the vehicle function of the second vehicle 20B whose risk score exceeds the first threshold value or exceeds the second threshold value.
  • the vehicle function of the first vehicle 20A corresponding to the vehicle function of the second vehicle 20B here is, for example, the same vehicle function as the vehicle function of the second vehicle 20B whose risk score exceeds each threshold value.
  • other vehicle functions provided by the ECU that provides vehicle functions that are restricted or disabled in the first vehicle 20A may be included in the corresponding vehicle functions.
  • the corresponding vehicle function is an ECU that provides a vehicle function with a risk score exceeding the first threshold value or the second threshold value in the second vehicle 20B, even though the function provided by the first vehicle 20A is different. And a vehicle function provided by an ECU of the same manufacturer or an ECU of the same type. Such a corresponding vehicle function is grasped by referring to the device list.
  • FIG. 23 is a flowchart showing an example of a procedure of a vehicle function restriction releasing process executed after recalculation of the risk score of the second vehicle 20B.
  • the risk determination unit 14 determines whether or not there is a change in the traveling state of the second vehicle 20B (step S2300).
  • the risk determination unit 14 recalculates the risk score related to the traveling state of the second vehicle 20B (steps in the procedure of the flowchart shown in FIG. 13). (Corresponding to S423 and S424) is executed (step S2400) and written in the risk level management list.
  • the risk determination unit 14 newly reads the recalculated risk score of the second vehicle 20B from the risk level management list, and thereafter, using this risk score, the procedure common to the processing procedure shown in FIG. 17 is executed. .
  • Steps S2700, S2701, S2710 and S2720 correspond to steps S700, S701, S710 and S720 in the first embodiment shown in FIG.
  • the determination as to the issuance of the function disabling instruction is made in step S2701 for the same reason that the function restriction is not released when the vehicle function is disabled in the first embodiment.
  • the possibility that the vehicle function of the first vehicle 20A is affected by the incident occurring in the second vehicle 20B changes depending on whether or not the communication with the second vehicle 20B can be established. That is, if the communication cannot be established, the influence of the incident occurring in the second vehicle 20B may not affect the vehicle function of the first vehicle 20A via the communication. Therefore, for example, the vehicle function of the first vehicle 20A is limited depending on whether or not the distance between the first vehicle 20A and the second vehicle 20B having a high risk level is a distance at which communication between vehicles can be established. It may be determined whether or not to do.
  • FIG. 24A is a flowchart showing a procedure example of a function restriction process for the vehicle function of the first vehicle 20A in this aspect. Further, FIG.
  • 24B is a flowchart showing an example of a procedure of a function limitation releasing process for the vehicle function of the first vehicle 20A after the function limitation instruction for the vehicle function of the first vehicle 20A is output in the procedure example shown in FIG. 24A. Is.
  • the risk determination unit 14 determines whether the risk score of the second vehicle 20B read from the risk level management list is equal to or higher than the first threshold value (step S2601A). When the risk score of the second vehicle 20B is equal to or higher than the first threshold value (Yes in step S2601A), the risk determination unit 14 further determines that the distance between the first vehicle 20A and the second vehicle 20B is less than the predetermined reference distance d. Determine if there is.
  • the reference distance d is determined, for example, based on the upper limit of the communicable distance according to the standard to which the communication established between the first vehicle 20A and the second vehicle 20B complies.
  • step S2602A When the distance between the first vehicle 20A and the second vehicle 20B is less than the reference distance d (Yes in step S2602A), the risk determination unit 14 in this example, the travel-related function among the vehicle functions of the first vehicle 20A.
  • the risk countermeasure instruction generation unit 16 is caused to generate a function restriction instruction for.
  • a function restriction instruction for this travel-related function is output from the instruction output unit 17 (step S2603A) and transmitted to the first vehicle 20A.
  • the vehicle function of the first vehicle 20A is determined. Function restriction instructions are not generated. In any of these cases, the influence of the incident occurring in the second vehicle 20B may not affect the vehicle function of the first vehicle 20A via communication. It is not necessary to implement security measures.
  • the target of the limitation is the traveling-related function, which is the most serious situation when the second vehicle 20B is traveling at a relatively short distance while traveling while being affected by the incident. This is because it is a traveling-related function that can be invited.
  • the risk determination unit 14 determines whether or not the distance between the first vehicle 20A and the second vehicle 20B is equal to or greater than the predetermined reference distance d. The determination is made (step S2701A). When the distance between the first vehicle 20A and the second vehicle 20B is equal to or greater than the predetermined reference distance d (Yes in step S2701A), even if an incident occurs in the second vehicle 20B, the effect of the incident is first via communication. Since there is no possibility of reaching the vehicle function of the vehicle 20A, a function restriction release instruction for the travel-related function for the vehicle function of the first vehicle 20A is generated and output (step S2702B).
  • this function restriction release instruction is not output. That is, the function restriction for the travel-related function in the first vehicle 20A is maintained.
  • the risk score of the second vehicle 20B may be increased when the incident history of the second vehicle 20B exists.
  • a vehicle that has a history of cyber-attack incidents may be left with some vulnerabilities that allowed the attack, or the effects of that attack may remain, and be vigilant and preventative measures for vehicles that can communicate with such vehicles. Is appropriate.
  • the risk score of the second vehicle 20B By setting the risk score of the second vehicle 20B to be equal to or higher than the first threshold value, the function limitation of the vehicle function is made in the first vehicle 20A. As a result, even if an incident occurs in the second vehicle 20B, it is possible to reduce the possibility that the influence will affect the vehicle function of the first vehicle 20A via communication.
  • FIG. 25 is a flowchart showing an example of a procedure of processing for security measures according to the incident history of such a second vehicle.
  • the risk determination unit 14 searches the incident information stored in the storage unit 2113 for a record of incident information regarding the second vehicle 20B (step S2900).
  • the risk score of the second vehicle 20B does not change.
  • the risk score of the second vehicle 20B is set to be equal to or higher than the first threshold value (step S2902).
  • the risk score set to be equal to or higher than the first threshold may be, for example, a risk score for the vehicle function according to the content of the found incident information record.
  • the risk score of the automatic driving function may be set to be equal to or higher than the first threshold.
  • the cyber attack that caused this incident is more likely to be affected by the same functional system than other functional systems.
  • the same functional system as the automatic driving function that is, driving assistance and driving control belonging to the driving system
  • the risk score of the function may be set to be equal to or higher than the first threshold.
  • the information processing device illustrated for the description of the above embodiments is a server
  • at least a part of the components of the information processing device is an in-vehicle information processing device such as one or more ECUs. May be.
  • the ECU 210A may have the same functional configuration as the security risk countermeasure server 10 or 10A.
  • FIG. 26 is a block diagram showing a functional configuration example of such an ECU 210A.
  • the vehicle information acquisition unit 2112 of FIG. 26 acquires the vehicle information of the first vehicle 20 by communication on the in-vehicle network rather than receiving it via the external communication network. Further, the function restriction instruction and the function restriction cancellation instruction output from the instruction output unit 2117 are directly sent to the vehicle-mounted network and do not pass through the external communication network.
  • the risk point management unit updates the risk points based on the incident information, that is, the steps in the flowchart of FIG.
  • the process up to S2 may be executed by the security risk countermeasure server, and the risk point table may be provided to the in-vehicle information processing device via the communication network.
  • the in-vehicle information processing device executes step S4 and subsequent steps using the provided latest risk point table and the vehicle information acquired from the other in-vehicle information processing device.
  • the creation (updating) of the risk level management list in step S4 in the flowchart of FIG. 5 is executed by the security risk countermeasure server, and the risk level management list is provided to the in-vehicle information processing device via the communication network. Good.
  • the in-vehicle information processing device executes step S5 and subsequent steps using the provided latest risk level management list.
  • the risk point table is also provided from the security risk countermeasure server to the in-vehicle information processing device, and the in-vehicle information processing device can perform a relatively small-scale update of the risk level related to the traveling position or the traveling state and the subsequent function restriction determination. It may be executed.
  • the vehicle information of the first vehicle may be provided to the security risk countermeasure server by daily processing at midnight of each day or the like.
  • the security risk countermeasure server updates the risk point table based on the incident information and the risk level management list of the first vehicle as a daily daily processing at night, and by the early morning, the security risk countermeasure server performs the first update.
  • the latest risk point table and risk level management list are transmitted to one vehicle.
  • the in-vehicle information processing device of the first vehicle executes small-scale updating of the risk level and determination of function limitation from early morning to late night.
  • the vehicle information of the first vehicle is provided to the security risk countermeasure server or the security risk countermeasure server transfers it to the first vehicle in response to the request of the driver of the first vehicle. Provision of the latest risk point table and risk level management list of the above may be implemented.
  • the mode of function restriction is not limited to the above description regarding the function restriction with reference to the risk level management list of FIG. 12 and FIG.
  • it may be a multi-step limitation determined by using more criteria.
  • relaxation of the functional restriction is conceptually included in the determination of cancellation of the functional restriction performed by the risk determination unit 14 or 2114.
  • the expression of the place where the incident occurs in the incident information and the traveling position of the vehicle in the vehicle information are not limited to the example using the place name such as the above-mentioned municipality, and the place where the incident is statistically large or small. It suffices if it is an expression that can understand the positional relationship between and the traveling position of the first vehicle.
  • a landmark or a facility name such as a communication base station, a road name and its section, latitude and longitude, or a grid map in which cells are arranged may be used to represent the traveling position.
  • the positional relationship can be expressed by, for example, the distance and direction, inclusion, or overlap with these.
  • the latitude and longitude information is acquired, for example, as the latitude and longitude information provided from each vehicle.
  • Other expressions may be realized, for example, in the incident information collection server 30 or the security risk countermeasure server 10 by converting from the latitude and longitude information provided by each vehicle.
  • the risk determination unit 14 or 2114 re-determines the risk level of the vehicle function when the traveling position of the first vehicle has a predetermined change that can change the risk level.
  • this predetermined change include switching of the nearest facility, switching of a road or its section, a change of a predetermined amount of longitude and latitude, and switching of a cell including a traveling position on a grid map.
  • Part or all of the constituent elements of each device in the above embodiments may be configured by one system LSI (Large Scale Integration).
  • the system LSI is an ultra-multifunctional LSI manufactured by integrating a plurality of constituent parts on one chip, and specifically, is a computer system including a microprocessor, ROM, RAM and the like. . A computer program is recorded in the RAM.
  • the system LSI achieves its function by the microprocessor operating according to the computer program.
  • each part of the constituent elements of each of the above-described devices may be individually made into one chip, or may be made into one chip so as to include a part or all.
  • the system LSI is used here, it may 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 it may be realized by a dedicated circuit or a general-purpose processor.
  • a field programmable gate array (FPGA) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • FPGA field programmable gate array
  • a reconfigurable processor that can reconfigure the connection and setting of circuit cells inside the LSI may be used.
  • Part or all of the constituent elements of each of the above devices may be configured with an IC card that can be attached to and detached from each device or a single module.
  • the IC card or module is a computer system including a microprocessor, ROM, RAM and the like.
  • the IC card or module may include the above-mentioned 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 be tamper resistant.
  • information processing including all or part of the processing procedure shown in FIG. 5, FIG. 8, FIG. 13 to FIG. 18C, FIG. 20, FIG. It may be a method. Further, it may be a program (computer program) that realizes these methods by a computer.
  • a computer-readable recording medium such as a flexible disk, a hard disk, a CD-ROM, a MO, a DVD, a DVD-ROM, which can read the above computer program or a digital signal representing the computer program.
  • it may be a digital signal recorded on these recording media.
  • the above computer program or digital signal may be transmitted via an electric communication line, a wireless or wired communication line, a network typified by the Internet, a data broadcast, or the like.
  • a computer system including a microprocessor and a memory may be used, in which the memory records the computer program and the microprocessor operates in accordance with the computer program.
  • the program or the digital signal may be recorded on a recording medium and transferred, or the program or the digital signal may be transferred via a network or the like to be implemented by another independent computer system.
  • the present invention can be used for an information processing device, an information processing method, and a program that process information used in a vehicle.

Landscapes

  • Engineering & Computer Science (AREA)
  • Mechanical Engineering (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Traffic Control Systems (AREA)

Abstract

Dispositif de traitement d'informations comprenant : une unité d'acquisition d'informations d'incident (11) qui acquiert des informations d'incident relatives à un enregistrement d'incidents impliquant un véhicule; une unité d'acquisition d'informations de véhicule (12) qui acquiert de premières informations de véhicule relatives à l'état d'un premier véhicule; une unité de stockage (13) qui stocke les informations d'incident et les premières informations de véhicule; une unité de détermination de risque (14) qui détermine le niveau de risque d'une fonction de véhicule du premier véhicule sur la base du degré de coïncidence entre les informations d'incident stockées et les premières informations de véhicule; une unité de génération d'instruction de contre-mesure de risque (16) qui génère une instruction de restriction de fonction pour la fonction de véhicule si le niveau de risque est supérieur à une première ligne de base; et une unité d'émission d'instruction (17) qui émet l'instruction de restriction de fonction.
PCT/JP2019/030795 2018-10-17 2019-08-06 Dispositif de traitement d'informations, procédé de traitement d'informations et programme WO2020079928A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CN201980067829.4A CN112867642B (zh) 2018-10-17 2019-08-06 信息处理装置、信息处理方法以及记录介质
EP19874667.9A EP3868617A4 (fr) 2018-10-17 2019-08-06 Dispositif de traitement d'informations, procédé de traitement d'informations et programme
US17/230,496 US11790088B2 (en) 2018-10-17 2021-04-14 Information processing device, information processing method, and recording medium

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201862746844P 2018-10-17 2018-10-17
US62/746,844 2018-10-17
JP2019098725A JP7344009B2 (ja) 2018-10-17 2019-05-27 情報処理装置、情報処理方法及びプログラム
JP2019-098725 2019-05-27

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US17/230,496 Continuation US11790088B2 (en) 2018-10-17 2021-04-14 Information processing device, information processing method, and recording medium

Publications (1)

Publication Number Publication Date
WO2020079928A1 true WO2020079928A1 (fr) 2020-04-23

Family

ID=70283041

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/030795 WO2020079928A1 (fr) 2018-10-17 2019-08-06 Dispositif de traitement d'informations, procédé de traitement d'informations et programme

Country Status (1)

Country Link
WO (1) WO2020079928A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004030286A (ja) * 2002-06-26 2004-01-29 Ntt Data Corp 侵入検知システムおよび侵入検知プログラム
JP2007058514A (ja) * 2005-08-24 2007-03-08 Mitsubishi Electric Corp 情報処理装置及び情報処理方法及びプログラム
JP2014146868A (ja) 2013-01-28 2014-08-14 Hitachi Automotive Systems Ltd ネットワーク装置およびデータ送受信システム
JP2017111796A (ja) * 2015-12-16 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
JP2017167916A (ja) * 2016-03-17 2017-09-21 株式会社デンソー 情報処理システム
JP2018041200A (ja) * 2016-09-06 2018-03-15 住友電気工業株式会社 車載通信機、管理装置、管理方法および監視プログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004030286A (ja) * 2002-06-26 2004-01-29 Ntt Data Corp 侵入検知システムおよび侵入検知プログラム
JP2007058514A (ja) * 2005-08-24 2007-03-08 Mitsubishi Electric Corp 情報処理装置及び情報処理方法及びプログラム
JP2014146868A (ja) 2013-01-28 2014-08-14 Hitachi Automotive Systems Ltd ネットワーク装置およびデータ送受信システム
JP2017111796A (ja) * 2015-12-16 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
JP2017167916A (ja) * 2016-03-17 2017-09-21 株式会社デンソー 情報処理システム
JP2018041200A (ja) * 2016-09-06 2018-03-15 住友電気工業株式会社 車載通信機、管理装置、管理方法および監視プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3868617A4 *

Similar Documents

Publication Publication Date Title
JP2020065242A (ja) 情報処理装置、情報処理方法及びプログラム
JP7197638B2 (ja) セキュリティ処理方法及びサーバ
US20200195472A1 (en) Security device, network system, and fraud detection method
US11797687B2 (en) Information processing device, information processing method, and recording medium
CN112437056B (zh) 安全处理方法以及服务器
JP7369843B2 (ja) 検証方法、検証装置およびプログラム
WO2020080222A1 (fr) Appareil d'analyse de menace, procédé d'analyse de menace et programme
US11829472B2 (en) Anomalous vehicle detection server and anomalous vehicle detection method
WO2020079943A1 (fr) Dispositif de traitement d'informations, procédé de traitement d'informations et programme
WO2020079928A1 (fr) Dispositif de traitement d'informations, procédé de traitement d'informations et programme
JP7496404B2 (ja) セキュリティ処理方法及びサーバ
KR20240010427A (ko) 통지 장치, 통지 방법, 및 컴퓨터 판독가능한 저장매체

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: 19874667

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019874667

Country of ref document: EP

Effective date: 20210517