WO2020075801A1 - 情報処理装置、異常分析方法及びプログラム - Google Patents

情報処理装置、異常分析方法及びプログラム Download PDF

Info

Publication number
WO2020075801A1
WO2020075801A1 PCT/JP2019/040017 JP2019040017W WO2020075801A1 WO 2020075801 A1 WO2020075801 A1 WO 2020075801A1 JP 2019040017 W JP2019040017 W JP 2019040017W WO 2020075801 A1 WO2020075801 A1 WO 2020075801A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
log
unit
context
feature
Prior art date
Application number
PCT/JP2019/040017
Other languages
English (en)
French (fr)
Inventor
慶太 長谷川
卓麻 小山
靖 岡野
田中　政志
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to EP19871518.7A priority Critical patent/EP3842944A4/en
Priority to CN201980064266.3A priority patent/CN112805687A/zh
Priority to US17/280,823 priority patent/US11863574B2/en
Priority to JP2020551221A priority patent/JP7180686B2/ja
Publication of WO2020075801A1 publication Critical patent/WO2020075801A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/552—Detecting local intrusion or implementing counter-measures involving long-term monitoring or reporting
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1425—Traffic logging, e.g. anomaly detection
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0751—Error or fault detection not based on redundancy
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00—Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/40—Data acquisition and logging
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]
    • H04W12/122—Counter-measures against attacks; Protection against rogue devices
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/46—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for vehicle-to-vehicle communication [V2V]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • the present invention relates to an information processing device, an abnormality analysis method, and a program.
  • Non-Patent Document 1 discloses a technique for coping with cyber-attacks in cooperation with server clients such as that described in (1).
  • Abnormalities such as cyber attacks on vehicles are often an overwhelmingly small number of events in terms of the total number of detected cases.
  • the detection result often includes false positive false detections caused by operation mistakes, setting changes, changes in environmental factors, and the like.
  • an anomaly that may be a cyber attack is detected, it is necessary to analyze the decision method to be taken according to the detection result, but such false detection increases the analysis cost. There's a problem.
  • the present invention has been made in view of the above points, and an object thereof is to reduce the cost of analyzing data output by a device.
  • the information processing apparatus associates the first data output by any one of the one or the plurality of devices with the first feature context related to the first data.
  • the second data is received from the storage processing unit that stores the data in the storage unit and one of the one or the plurality of devices
  • the second feature context related to the second data is acquired
  • an abnormality of the received second data is detected.
  • an analyzing unit for analyzing.
  • the cost of analyzing the data output by the device can be reduced.
  • FIG. 9 is a flowchart illustrating an example of a processing procedure when a log is generated. It is a figure which shows the structural example of a log. It is a figure which shows the structural example of a log. It is a figure which shows the structural example of a log. It is a figure which shows the structural example of control system log DB271. It is a figure which shows the structural example of sensor log DB272.
  • 9 is a flowchart illustrating an example of a processing procedure when a log is received. It is a figure which shows the structural example of characteristic knowledge DB173. 9 is a flowchart illustrating an example of a processing procedure when determining a coping method.
  • FIG. 1 is a diagram showing a system configuration example in the embodiment of the present invention.
  • a plurality of vehicles 20 are automobiles (connected cars) connected to various servers (monitoring server 10, service providing server 30a, service providing server 30b, etc.) via a network N1 such as the Internet.
  • a network N1 such as the Internet.
  • each vehicle 20 connects to the network N1 via a wireless network such as a mobile communication network and communicates with various servers.
  • the service providing server 30a, the service providing server 30b, and the like (hereinafter, referred to as "service providing server 30" when they are not distinguished from each other) provide a predetermined service to the vehicle 20 or based on information collected from the vehicle 20.
  • One or more computers provided may provided.
  • the service providing server 30a may provide a telematics service.
  • the service providing server 30b may provide a service based on the data collected from each vehicle 20.
  • the monitoring server 10 is one or more computers that detect the occurrence of an abnormality in the vehicle 20, analyze the content of the abnormality, and the like, based on the data transmitted (uploaded) from the vehicle 20.
  • An example of the abnormality is a cyber attack on the vehicle 20 via a network.
  • FIG. 2 is a diagram showing a hardware configuration example of the monitoring server 10 according to the embodiment of the present invention.
  • the monitoring server 10 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, etc., which are mutually connected by a bus B.
  • a program that realizes the processing in the monitoring server 10 is provided by a recording medium 101 such as a CD-ROM.
  • a recording medium 101 such as a CD-ROM.
  • the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100.
  • the auxiliary storage device 102 stores the installed program and also stores necessary files and data.
  • the memory device 103 reads the program from the auxiliary storage device 102 and stores the program when an instruction to activate the program is given.
  • the CPU 104 executes the function related to the monitoring server 10 according to the program stored in the memory device 103.
  • the interface device 105 is used as an interface for connecting to a network.
  • FIG. 3 is a diagram showing a hardware configuration example of the vehicle 20 according to the embodiment of the present invention.
  • the vehicle 20 includes a communication device 210, an information subsystem 220, a control subsystem 230, a barrier device 240, and the like.
  • the communication device 210 connects with a communication module for connecting to the network N1, a communication module for communicating with another vehicle 20 or a device on the road, or a smartphone or the like via a wireless LAN or short-range wireless communication. It includes a communication module for
  • the information subsystem 220 is a part that executes information processing according to the installed program, and includes a CPU 221, a memory device 222, an auxiliary storage device 223, a display device 224, an input device 225, and the like.
  • the auxiliary storage device 223 stores the installed program and various data used by the program.
  • the memory device 222 reads the program to be activated from the auxiliary storage device 223 and stores it.
  • the CPU 221 executes the function related to the information subsystem 220 according to the program stored in the memory device 222.
  • the display device 224 displays a GUI (Graphical User Interface) or the like according to the program.
  • the input device 225 is an operation component such as a button or a touch panel, and is used to input various operation instructions. Note that, for example, an in-vehicle device such as a car navigation or car audio head unit is an example of the information subsystem 220.
  • the control subsystem 230 is a part that controls the behavior of the vehicle 20, and includes a plurality of microcomputers 231 for various controls.
  • a microcomputer for example, an ECU (Electronic Control Unit) is an example of the microcomputer 231.
  • the gateway 240 is a gateway (for example, CGW (Central Gateway)) for connecting the information subsystem 220 and the control subsystem 230. That is, the communication protocol handled by the information subsystem 220 is, for example, the IP protocol, and the communication protocol used for communication between the microcomputers 231 in the control subsystem 230 is a non-IP protocol specialized for control (for example, , CAN (Controller Area Network)). Therefore, the barrier 240 for absorbing the difference between these communication protocols is provided.
  • CGW Central Gateway
  • FIG. 3 is just an example.
  • the hardware configuration of the vehicle 20 is not limited to a specific one as long as the functions described below can be realized.
  • FIG. 4 is a diagram showing a functional configuration example of the vehicle 20 and the monitoring server 10 in the embodiment of the present invention.
  • the information subsystem 220 of the vehicle 20 includes a control system log acquisition unit 251, a sensor log generation unit 252, an abnormality determination unit 253, a feature context generation unit 254, a log transmission unit 255, a detection algorithm reception unit 256, and the like.
  • Each of these units is realized by a process that causes the CPU 221 to execute one or more programs installed in the information subsystem 220.
  • the information system subsystem 220 also has a database (storage unit) such as a control system log DB 271, a sensor log DB 272, and a detection algorithm DB 273.
  • Each of these databases (storage unit) can be realized using, for example, the memory device 222, the auxiliary storage device 223, or the like.
  • the control system log acquisition unit 251 acquires the control system log and stores (stores) it in the control system log DB 271.
  • the control system log refers to log data relating to communication by each microcomputer 231 in the control system subsystem 230.
  • the communication content data itself may be used as the control system log. Therefore, the control system log is generated every time communication is performed by any one of the microcomputers 231.
  • the content of the communication indicates, for example, content of communication regarding control of the vehicle 20, information of infoment system such as audio and car navigation, indicator display in the vehicle 20, and the like.
  • the sensor log generation unit 252 generates a sensor log and stores it in the sensor log DB 272.
  • the sensor log refers to log data including data (for example, a measurement value by the sensor) acquired from a sensor (for example, an accelerometer, a GPS (Global Positioning System) receiver, or the like) arranged in each place of the vehicle 20. . Acquisition of data from each sensor and generation of a sensor log based on the data are executed, for example, at a fixed cycle or at a timing such as occurrence of a specific event. The sensor log generation timing may be different for each sensor.
  • the sensor for which the sensor log is generated may be a part of all the sensors included in the vehicle 20.
  • the abnormality determination unit 253 uses the detection algorithm stored in the detection algorithm DB 273 based on the control system log and the sensor log (hereinafter, simply referred to as “log” when they are not distinguished from each other), and determines the degree of abnormality (level). ) Is determined. Specifically, the abnormality determination unit 253 calculates an index value (hereinafter, referred to as “abnormality score”) indicating the degree of abnormality of the log generated from the vehicle 20. However, only the control system log or only the sensor log may be used to calculate the abnormality score. The calculated abnormality score is stored in the control system log DB 271 or the sensor log DB 272.
  • the characteristic context generation unit 254 generates information related to the log (hereinafter, referred to as “characteristic context”) indicating a situation such as the external environment of the vehicle 20 when the log is acquired or generated, the state of the vehicle 20, and the like. .
  • the feature context generation unit 254 when the abnormality score is calculated, the feature context generation unit 254 generates a feature context indicating the time when the log is acquired or generated, the external environment of the vehicle 20, the state of the vehicle 20, and the like.
  • the characteristic context may be generated based on the log stored in the control system log DB 271 or the sensor log DB 272, or may be generated based on the information acquired from the communication device 210.
  • the log transmission unit 255 sets the characteristic context in the log stored in the control system log DB 271 or the sensor log DB 272. It is given and transmitted to the monitoring server 10.
  • the detection algorithm receiving unit 256 receives the detection algorithm change request distributed from the monitoring server 10 and changes (updates) the detection algorithm DB 273 with the detection algorithm included in the change request.
  • the monitoring server 10 includes a log receiving unit 151, an erroneous detection / coping method determining unit 152, a detection algorithm changing unit 153, a detection algorithm transmitting unit 154, a coping method registration unit 155, and the like.
  • Each of these units is realized by a process that causes the CPU 104 to execute one or more programs installed in the monitoring server 10.
  • the monitoring server 10 also uses databases (storage unit) such as a control system log DB 171, a sensor log DB 172, a characteristic knowledge DB 173, and a detection algorithm DB 174.
  • Each of these databases (storage unit) can be realized by using, for example, the auxiliary storage device 102 or a storage device that can be connected to the monitoring server 10 via a network.
  • the log receiving unit 151 receives a log transmitted (uploaded) from the vehicle 20, and stores the log in the control system log DB 171 or the sensor log DB 172. Further, the log receiving unit 151 stores the identification information of the microcomputer 231 or the sensor that is the output source of the log, the abnormality score of the log, the feature context, and the like in the feature knowledge DB 173.
  • the erroneous detection / countermeasure method determining unit 152 analyzes the abnormality of the log received by the log receiving unit 151.
  • the erroneous detection / coping method determination unit 152 determines whether the abnormality is caused by the erroneous detection of the abnormality determination unit 253.
  • the erroneous detection / coping method determination unit 152 extracts, from the feature knowledge DB 173, a past record that matches or is similar to the set of the log and the feature context received by the log reception unit 151.
  • the past records may be related to different vehicles or may be related to the same vehicle (obtained at different times).
  • the erroneous detection / coping method determination unit 152 determines the abnormality determination unit. Even if an abnormality of the log is detected in 253, it is determined that the abnormality is caused by the over-detection of the abnormality determining unit 253.
  • the erroneous detection / countermeasure method determining unit 152 may request the detection algorithm changing unit 153 to change the detection algorithm when determining that the detection is excessive.
  • the erroneous detection / coping method determining unit 152 implements the coping method for the log as well.
  • Examples of coping methods include changing the abnormality score of the feature knowledge DB 173 by treating it as false detection, changing the detection algorithm, and the like.
  • a warning that detailed analysis is necessary may be output.
  • the detection algorithm changing unit 153 changes a part or all of the detection algorithms stored in the detection algorithm DB 174 in response to a request from the erroneous detection / measurement method determining unit 152.
  • the detection algorithm DB 174 stores the detection algorithm distributed to each vehicle 20.
  • the detection algorithm transmitting unit 154 delivers a change request including the detection algorithm changed by the detection algorithm changing unit 153 to each vehicle 20.
  • the coping method registration unit 155 registers, in the feature knowledge DB 173, the coping method input by the analyst or the like in response to the warning that the erroneous detection / coping method determination unit 152 requires detailed analysis.
  • the abnormality score is calculated and the characteristic context is generated in the vehicle 20
  • the abnormality score may be calculated or the characteristic context may be generated in the monitoring server 10.
  • the anomaly score or the feature context may be manually input by an analyst or the like.
  • the log transmission unit 255 transmits the log to the monitoring server 10 when the transmission timing arrives.
  • the abnormality determination unit (not shown) of the monitoring server 10 calculates an abnormality score similarly to the abnormality determination unit 253 of the vehicle 20, and stores the abnormality score in the control system log DB 171 or the sensor log DB 172.
  • the characteristic context generation unit (not shown) of the monitoring server 10 When the characteristic context is generated in the monitoring server 10, the characteristic context generation unit (not shown) of the monitoring server 10 generates the characteristic context in the same manner as the characteristic context generation unit 254 of the vehicle 20, and the characteristic context is converted into the characteristic knowledge. It is stored in the DB 173.
  • the characteristic context may be generated based on the log stored in the control system log DB 171 or the sensor log DB 172 of the monitoring server 10, or may be generated based on the information acquired via the interface device 105.
  • FIG. 5 is a flowchart for explaining an example of a processing procedure when a log is generated.
  • target log One of the logs (hereinafter referred to as “target log”) is stored in the control system log DB 271 or the sensor log DB 272 by the control system log acquisition unit 251 acquiring the control system log, the sensor log generation unit 252 generating the sensor log, or the like. (S101).
  • FIG. 6A and 6B are diagrams showing a configuration example of a log.
  • FIG. 6A shows an example of the control system log.
  • the control system log includes the date and time, the vehicle ID, the element ID, Data [0], Data [1], Data [2], Data [3], Data [4], etc. (hereinafter, "Data []”). ".) And.
  • the date and time is the date and time when the control system log was acquired (the date and time when communication related to the control system log was performed).
  • the vehicle ID is identification information of the vehicle 20.
  • the element ID is identification information of the constituent elements of the vehicle 20.
  • the element ID in the control system log is identification information of the microcomputer 231 that has performed communication related to the control system log.
  • Data [] is data included in the communication. For example, if the communication is communication related to engine control, the value of each parameter related to engine control becomes the value of each Data []. However, not only the value of each parameter related to engine control, but also data such as checksum and counter may
  • FIG. 6B shows an example of the sensor log.
  • the sensor log includes the date and time, the vehicle ID and the element ID, and the data specific to the sensor related to the sensor log.
  • the date and time is the date and time when the sensor log was generated.
  • the vehicle ID is identification information of the vehicle 20.
  • the element ID is identification information of the sensor that is the output source of the data related to the sensor log.
  • the sensor log in FIG. 6B is a sensor log based on the data acquired from the acceleration sensor, and therefore includes Acc_X, Acc_Y, and Acc_Z as data unique to the acceleration sensor.
  • Acc_X, Acc_Y, and Acc_Z are acceleration in the X-axis direction, acceleration in the Y-axis direction, and acceleration in the Z-axis direction, respectively.
  • FIG. 7 is a diagram showing a configuration example of the control system log DB 271.
  • each record in the control system log DB 271 includes each item shown in FIG. 6A and an abnormality score.
  • the value of the abnormality score is empty at the time of step S101. This is because the value of the abnormality score is determined in step S102.
  • FIG. 8 is a diagram showing a configuration example of the sensor log DB 272.
  • each record of the sensor log DB 272 includes each item shown in FIG. 6B and an abnormality score.
  • the value of the abnormality score is empty for the same reason as in the control system log DB 271.
  • the format of the sensor log differs depending on the sensor. For example, a sensor log of a GPS receiver includes latitude and longitude. Therefore, in the sensor log DB 272, the sensor logs may be stored in different tables for each sensor (each element ID).
  • the abnormality determination unit 253 determines (calculates) the abnormality score for the target log and stores it in the control system log DB 271 or the sensor log DB 272 (S102).
  • the anomaly score determination may be performed at regular intervals or in response to the occurrence of logs that include a specific value, and is performed each time a certain amount of logs required for anomaly determination is saved. May be.
  • the judgment (calculation) of the anomaly score for the target log can be performed using known technology.
  • the abnormality score may be determined based on the communication interval between the microcomputers 231 or the data value output by the microcomputer 231. Further, for example, the abnormality score may be determined by inputting the target log to a learned model (for example, a neural network) that inputs the log and outputs the abnormality score.
  • the abnormality score may be 0 or 1 indicating the presence or absence of abnormality, or may be a value indicating the degree of abnormality in the range of the minimum value (for example, 0) to the maximum value (for example, 1). Further, the determination of the abnormality score does not have to be performed using both the control system log and the sensor log. For example, the abnormality score may be determined by using only one of the control system log and the sensor log.
  • the characteristic context generation unit 254 generates a characteristic context for the target log when the abnormality determination unit 253 determines an abnormality score (S103).
  • the feature context generation unit 254 not only generates the feature context when the anomaly score of the target log is equal to or higher than the anomaly detection threshold, that is, when the anomaly score of the target log is less than the anomaly detection threshold.
  • the feature context may be generated in some cases, that is, when it is detected as normal.
  • the characteristic context generation unit 254 generates a spatial characteristic context indicating the external environment of the vehicle 20, a temporal characteristic context indicating the time when the log is acquired or generated, a behavioral characteristic context indicating the behavior of the vehicle 20, and the like. Further, a traffic domain-dependent context indicating information on the traffic condition of the vehicle 20, a vehicle domain-dependent context indicating information on the state of the vehicle 20, and the like may be generated.
  • Examples of spatial feature contexts are weather, location, obstacles, temperature, rainfall, humidity, atmospheric pressure, wind speed, etc.
  • temporal feature contexts are hours, days of the week, seasons, events, etc.
  • Examples of behavioral feature contexts are velocities, accelerations, angular velocities, etc. obtained from sensors of the vehicle 20 or sensors of other vehicles.
  • Examples of traffic domain dependent contexts are travel routes, road surface conditions, traffic flow, slopes, elevations, widths, lanes, etc.
  • Examples of the vehicle domain-dependent context are vehicle type, year, presence / absence of option, failure history, mounted ECU, attack history, attack campaign information, and the like. Note that the classification of these feature contexts is merely for convenience, and for example, temperature, rainfall, humidity, atmospheric pressure, wind speed, etc. may be classified as temporal feature contexts, and gradients, elevations, etc., as spatial feature contexts. It may be classified. Also, any combination of the above feature contexts may be used, and other feature contexts may be used.
  • the feature context generation unit 254 when information such as weather and temperature can be acquired from a smartphone, an external server, or the like via the communication device 210, the feature context generation unit 254 generates a spatial feature context representing a weather environment. For example, the feature context generation unit 254 generates a spatial feature context representing the location of the vehicle 20 from the sensor log of the GPS receiver stored in the sensor log DB 272. For example, the feature context generation unit 254 uses the sensor log of the GPS receiver stored in the sensor log DB 272 and the control system log of the vehicle speed stored in the control system log DB 271 to represent the speed and acceleration of the vehicle 20. Generate a behavioral feature context. Each feature context may be generated as an instantaneous value, a continuous value or a discrete value within a period of time.
  • the log transmission unit 255 adds the characteristic context to the target log and transmits it to the monitoring server 10 (S104).
  • the log transmission unit 255 monitors both a log detected as abnormal (that is, a log whose abnormality score is equal to or greater than the abnormality detection threshold) and a log detected as normal (that is, a log whose abnormality score is less than the abnormality detection threshold). 10 may be transmitted, a log detected as abnormal may be transmitted, and a log detected as normal may not be transmitted.
  • the log transmission unit 255 may select a log to be transmitted based on a preset priority or standard.
  • the determination of the abnormality score (S102) and the generation of the characteristic context (S103) may be executed by the monitoring server 10 after the monitoring server 10 receives the target log.
  • FIG. 9 is a flowchart for explaining an example of a processing procedure at the time of receiving a log.
  • the log receiving unit 151 receives the target log together with the feature context, stores the target log in the control system log DB 171 or the sensor log DB 172, and stores the feature context in the feature knowledge DB 173 (S201).
  • the control system log DB 171 and the sensor log DB 172 are configured similarly to FIGS. 7 and 8, respectively.
  • FIG. 10 is a diagram showing a configuration example of the feature knowledge DB 173.
  • each record of the feature knowledge DB 173 includes a feature context and a coping method in addition to the date and time, the vehicle ID, the element ID, and the abnormality score in the control system log DB 171 or the sensor log DB 172.
  • the feature context received by the log receiving unit 151 is stored in the feature context.
  • the coping method is empty because it is registered in step S303.
  • the vehicle 20 and the microcomputer 231 or the sensor that is the output source of the target log can be identified by the combination of the vehicle ID and the element ID.
  • the correspondence relationship between the record of the characteristic knowledge DB 173 and the record of the control system log DB 171 or the sensor log DB 172 may be identified by a set of date and time, vehicle ID, and element ID, and the record of the control system log DB 171 or the sensor log DB 172. It may be identified by adding the log ID indicating “” to the feature knowledge DB 173.
  • step S202 If the abnormality score is equal to or higher than the abnormality detection threshold value (S202: Yes), the following processing is executed. If the log transmission unit 255 of the vehicle 20 does not transmit the log whose abnormality score is less than the abnormality detection threshold value, step S202 may not be performed.
  • the erroneous detection / coping method determination unit 152 determines (calculates) the degree of similarity between the target log or the feature context and the past record stored in the feature knowledge DB 173 (S203).
  • the continuous value may be converted into a discrete value for determining the similarity.
  • the matching or similar determination method can be performed using a known technique. For example, exact match or partial match may be used. In addition, for example, for a learned model (for example, a neural network) that inputs various logs and feature contexts and outputs the respective degrees of similarity, one of the target log and feature contexts and the feature knowledge DB 173 The similarity may be determined by inputting the record. In addition, statistical processing such as an outlier test may be performed. The determination of matching or similar feature contexts may be performed across multiple feature contexts. When the determination is performed over a plurality of contexts, the weight according to the feature context may be applied.
  • the erroneous detection / coping method determining unit 152 implements the coping method (S206).
  • a behavioral feature context indicating the behavior of the brake is generated from the control system log of the microcomputer 231.
  • Information obtained by the sensor log of the GPS receiver, the sensor log of the camera or the distance sensor, VICS (registered trademark) (Vehicle Information and Communication System) information, V2V (Vehicle-to-Vehicle) or V2I (Vehicle-to-Infrastructure) From the above, it is assumed that a spatial feature context indicating the location of the vehicle 20 and a traffic domain-dependent context indicating occurrence of congestion are generated.
  • Other feature contexts such as a vehicle domain dependent context that indicates the state of the vehicle 20, are also generated, but a higher weight is applied to the feature contexts that are relevant to brake control.
  • the weight is a coefficient added to the feature context in the determination of abnormality including false detection, and may be implemented in the form of a logarithmic coefficient for the feature context, for example.
  • a high weight is applied to these feature contexts.
  • the erroneous detection / coping method determination unit 152 searches the feature knowledge DB 173 for matching or similar past records.
  • the erroneous detection / countermeasure determination unit 152 determines that the erroneous detection has occurred due to the traffic jam, and the control system of the microcomputer 231 in the feature knowledge DB 173. Update the anomaly score value for the log. If a coping method that can be automatically executed is set for the matching or similar past record, the erroneous detection / coping method determining unit 152 executes the coping method.
  • a behavioral feature context indicating the wiper behavior is generated from the control system log of the microcomputer 231. It is assumed that a spatial feature context indicating that the weather is rainy is generated from an external server, and a vehicle domain-dependent context indicating a vehicle type is generated.
  • a high weight is applied to these feature contexts.
  • the erroneous detection / coping method determination unit 152 searches the feature knowledge DB 173 for matching or similar past records.
  • the erroneous detection / countermeasure determination unit 152 determines that erroneous detection has occurred because the threshold for determining the abnormality of the wiper is not appropriate. Then, in the feature knowledge DB 173, the value of the abnormality score regarding the control system log of the microcomputer 231 is updated. If a coping method that can be automatically executed is set for the matching or similar past record, the erroneous detection / coping method determining unit 152 executes the coping method.
  • the erroneous detection / countermeasure method determination unit 152 outputs a warning that detailed analysis is necessary because the detection is unknown (S207). The warning may be notified from the monitoring server 10 to another analyzer, an analyst, or the like.
  • Another analyzer, an analyst, or the like refers to the log saved in the control system log DB 171 or the sensor log DB 172 and the feature context saved in the feature knowledge DB 173 to analyze the abnormality. Since the characteristic context is added to the log, it is possible to determine whether or not a large-scale abnormality (abnormality across a plurality of vehicles 20) such as a cyber attack may occur.
  • the method of analyzing such an abnormality is not limited to a predetermined method. For example, it may be performed based on a learned model (neural network or the like), or may be performed using another known technique.
  • information such as CERT (Computer Emergency Response Team) of an automobile company, SOC (Security Operation Center) of another company, announcement from a security vendor, etc. is used to determine whether or not an abnormality may occur. Good.
  • the coping method is determined according to the analysis results of other analyzers or analysts. For example, for a log that is determined to be erroneous detection, a coping method that changes the detection algorithm so as not to be detected as an abnormality is determined. For example, for a log determined not to be an erroneous detection, a coping method such as inspection or repair of a failure portion, updating of software such as the microcomputer 231 and the auxiliary storage device 223 is determined.
  • FIG. 11 is a flowchart for explaining an example of a processing procedure when determining a coping method.
  • the coping method registration unit 155 receives the coping method determined by another analyzer or an analyst (S301).
  • coping methods there are coping methods that can be automatically implemented and coping methods that cannot be automatically implemented because inspection or repair at a dealer is required.
  • the detection algorithm used by the abnormality determination unit 253 is changed, it is treated as an erroneous detection, and notification is given to a preset contact such as the owner of the vehicle 20. Is included.
  • the coping method registration unit 155 When the coping method registration unit 155 receives a coping method that can be automatically executed (S302: Yes), the coping method registration unit 155 registers the coping method in the feature knowledge DB 173 (S303). It should be noted that, even for a coping method that cannot be automatically implemented, the content that the method cannot be automatically implemented may be registered in the characteristic knowledge DB 173.
  • the erroneous detection / coping method determining unit 152 requests the detection algorithm changing unit 153 to change the detection algorithm
  • the algorithm changing unit 153 changes the detection algorithm stored in the detection algorithm DB 174 (S305).
  • the change of the detection algorithm includes the change of the feature amount extraction method used by the abnormality determination unit 253, the change of the weight for the feature amount, the adjustment of the threshold value, the setting of the white list indicating the condition that is not determined to be abnormal.
  • the detection algorithm transmitting unit 154 transmits the detection algorithm to the vehicle 20 via the interface device 150 such as wireless (S306).
  • the transmission of the detection algorithm may be performed at regular intervals, or may be performed according to the change of the detection algorithm.
  • the detection algorithm transmission unit 154 notifies the preset contact information such as the owner of the vehicle 20 that the update of the detection algorithm is necessary, and the update of the detection algorithm in the vehicle 20 is performed by the dealer or the like. May be.
  • the detection algorithm receiving unit 256 of the vehicle 20 receives the detection algorithm and changes the detection algorithm DB 273. The changed detection algorithm is used to determine the abnormality score in step S102 of FIG.
  • the characteristic context is added to the log, it becomes easy to understand the state in which the abnormality is detected. As a result, it is possible to reduce the cost required for the determination of the correctness / incorrectness of the detection result and the analysis of meaning. Further, by updating the detection algorithm according to the determination that the detection is false, the occurrence of false detection can be reduced.
  • the vehicle 20 has been described as an example of the device, but the present embodiment may be applied to other devices having a communication function.
  • industrial control devices such as robots in factories, sensors located in various places, audio devices, home appliances, communication terminals (smartphones, tablet terminals, etc.), and devices commonly called IoT (Internet of Things) devices.
  • IoT Internet of Things
  • the present embodiment may be applied.
  • the characteristic context is added to the data (log) generated in the vehicle 20 and transmitted to the monitoring server 10.
  • the monitoring server 10 can reduce the cost required for log analysis by associating the transmitted log and the characteristic context with each other and storing them in the characteristic knowledge DB 173.
  • the monitoring server 10 can reduce the amount of logs to be analyzed by an analyst or the like by registering a coping method that can be automatically implemented in the characteristic knowledge DB 173.
  • the monitoring server 10 can reduce the occurrence of over-detection by changing the detection algorithm of the vehicle 20 so that the over-detection does not occur when the over-detection occurs.
  • the vehicle 20 is an example of a device in the present embodiment.
  • the monitoring server 10 is an example of an information processing device.
  • the log receiving unit 151 is an example of a storage processing unit.
  • the false detection / countermeasure method determination unit 152 is an example of an analysis unit.
  • the coping method registration unit 155 is an example of a registration unit.
  • the detection algorithm changing unit 153 and the detection algorithm transmitting unit 154 are examples of changing units.
  • monitoring server 20 vehicle 30a service providing server 30b service providing server 100 drive device 101 recording medium 102 auxiliary storage device 103 memory device 104 CPU 105 Interface Device 151 Log Receiving Unit 152 False Detection / Coping Method Judgment Unit 153 Detection Algorithm Changing Unit 154 Detection Algorithm Transmission Unit 155 Coping Method Registration Unit 171 Control System Log DB 172 Sensor log DB 173 Feature Knowledge DB 174 Detection Algorithm DB 210 communication device 221 CPU 222 memory device 223 auxiliary storage device 224 display device 225 input device 220 information system subsystem 230 control system subsystem 231 microcomputer 240 barrier device 251 control system log acquisition unit 252 sensor log generation unit 253 abnormality determination unit 254 feature context generation unit 255 log transmission Unit 256 Detection algorithm receiving unit 271 Control system log DB 272 Sensor log DB 273 Detection algorithm DB B bus

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Quality & Reliability (AREA)
  • Databases & Information Systems (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • Debugging And Monitoring (AREA)
  • Traffic Control Systems (AREA)

Abstract

１つ又は複数の機器のうちいずれかの機器が出力した第１のデータを、当該第１のデータに関連する第１の特徴コンテキストと対応付けて記憶部に格納する記憶処理部と、１つ又は複数の機器のうちいずれかの機器から第２のデータを受信した場合、当該第２のデータに関連する第２の特徴コンテキストを取得し、当該受信した第２のデータ及び当該取得した第２の特徴コンテキストと、前記記憶部に格納された第１のデータ及び第１の特徴コンテキストとに基づいて、当該受信した第２のデータの異常を分析する分析部とを有する。

Description

情報処理装置、異常分析方法及びプログラム
　本発明は、情報処理装置、異常分析方法及びプログラムに関する。
　今後普及が見込まれるコネクテッドカー（外部ネットワークに接続する車両）においては、従来においてディーラーでの持ち込み作業であったＥＣＵ（Electronic Control Unit）のソフトウェアアップデートが無線で行われるなど、利便性の向上が期待されている。
　一方で、車両やその制御機器が外部ネットワークに繋がることにより、従来のＩＴ機器同様、悪意の有る攻撃者からのサイバー攻撃の対象となる懸念が指摘されている。実際に車両に搭載されたＥＣＵを、外部ネットワークからのアクセスによって不正に改竄し、車両制御を乗っ取ることが可能であったとする研究も報告されている。
　このような脅威に対して、様々な事前の対策技術が検討されているが、サイバー攻撃のリスクを完全に防ぐような対策手段というものは存在しない。したがって、万が一サイバー攻撃が発生した場合に対しても有効な事後の対策を考えておく必要がある。ＥＣＵを改竄することで車両の制御を乗っ取るような攻撃を考えた場合、車両での対策を取るためには、車載ネットワークで発生する通信を継続的に監視し、異常を検出する手法がある。しかしながら、一般に車載機器の計算リソースは潤沢ではない場合が多く、計算負荷の大きな異常検知手法は適用困難である場合が多い。
　そこで、昨今では、車両だけで対処するのではなく、クラウドと車両の双方を利用することによって、計算負荷の高い処理をクラウドで、計算負荷の低い処理や低遅延性が求められる処理を車載機で行うようなサーバクライアント連携でのサイバー攻撃への対処技術の検討が進んでいる（例えば、非特許文献１）。
"サイバー攻撃に対抗するオートモーティブ侵入検知防御システムを開発"、［online］、インターネット＜ＵＲＬ：https://news.panasonic.com/jp/press/data/2017/10/jn171010-2/jn171010-2.html＞
　車両に対するサイバー攻撃等の異常は、検知された全体の数から見れば圧倒的少数の事象であることが多い。つまり検知結果には、操作のミスや設定の変更、環境要因の変動等によって発生した、擬陽性の誤検知が含まれることが多い。サイバー攻撃の可能性があるという異常が検知された場合、検知結果に伴って実施すべき対処方法の決定等の分析を行う必要があるが、上記のような誤検知は分析コストを増加させるという問題がある。
　なお、上記のような問題は、車両に限られず、ネットワークに接続される各種の機器について共通の課題であると考えられる。
　本発明は、上記の点に鑑みてなされたものであって、機器が出力したデータを分析するコストを低減することを目的とする。
　そこで上記課題を解決するため、情報処理装置は、１つ又は複数の機器のうちいずれかの機器が出力した第１のデータを、当該第１のデータに関連する第１の特徴コンテキストと対応付けて記憶部に格納する記憶処理部と、１つ又は複数の機器のうちいずれかの機器から第２のデータを受信した場合、当該第２のデータに関連する第２の特徴コンテキストを取得し、当該受信した第２のデータ及び当該取得した第２の特徴コンテキストと、前記記憶部に格納された第１のデータ及び第１の特徴コンテキストとに基づいて、当該受信した第２のデータの異常を分析する分析部とを有する。
　機器が出力したデータを分析するコストを低減することができる。
本発明の実施の形態におけるシステム構成例を示す図である。 本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。 本発明の実施の形態における車両２０のハードウェア構成例を示す図である。 本発明の実施の形態における車両２０及び監視サーバ１０の機能構成例を示す図である。 ログの発生時における処理手順の一例を説明するためのフローチャートである。 ログの構成例を示す図である。 ログの構成例を示す図である。 制御系ログＤＢ２７１の構成例を示す図である。 センサログＤＢ２７２の構成例を示す図である。 ログの受信時における処理手順の一例を説明するためのフローチャートである。 特徴ナレッジＤＢ１７３の構成例を示す図である。 対処方法の決定時における処理手順の一例を説明するためのフローチャートである。
　以下、図面に基づいて本発明の実施の形態を説明する。図１は、本発明の実施の形態におけるシステム構成例を示す図である。図１において、複数の車両２０は、インターネット等のネットワークＮ１を介して各種のサーバ（監視サーバ１０、サービス提供サーバ３０ａ、サービス提供サーバ３０ｂ等）に接続される自動車（コネクテッドカー）である。例えば、各車両２０は、移動体通信網等の無線ネットワークを介してネットワークＮ１に接続し、各種のサーバと通信する。
　サービス提供サーバ３０ａ及びサービス提供サーバ３０ｂ等（以下、それぞれを区別しない場合「サービス提供サーバ３０」という。）は、車両２０に対して、又は車両２０から収集される情報に基づいて所定のサービスを提供する１以上のコンピュータである。例えば、サービス提供サーバ３０ａは、テレマティクスサービスを提供してもよい。また、サービス提供サーバ３０ｂは、各車両２０から収集されるデータに基づくサービスを提供してもよい。
　監視サーバ１０は、車両２０から送信（アップロード）されるデータに基づいて、車両２０における異常の発生の検知や、異常の内容の解析等を行う１以上のコンピュータである。異常の一例として、車両２０に対するネットワークを介したサイバー攻撃等が挙げられる。
　図２は、本発明の実施の形態における監視サーバ１０のハードウェア構成例を示す図である。図２において、監視サーバ１０は、それぞれバスＢで相互に接続されているドライブ装置１００、補助記憶装置１０２、メモリ装置１０３、ＣＰＵ１０４、及びインタフェース装置１０５等を有する。
　監視サーバ１０での処理を実現するプログラムは、ＣＤ－ＲＯＭ等の記録媒体１０１によって提供される。プログラムを記憶した記録媒体１０１がドライブ装置１００にセットされると、プログラムが記録媒体１０１からドライブ装置１００を介して補助記憶装置１０２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１０１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１０２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。
　メモリ装置１０３は、プログラムの起動指示があった場合に、補助記憶装置１０２からプログラムを読み出して格納する。ＣＰＵ１０４は、メモリ装置１０３に格納されたプログラムに従って監視サーバ１０に係る機能を実行する。インタフェース装置１０５は、ネットワークに接続するためのインタフェースとして用いられる。
　図３は、本発明の実施の形態における車両２０のハードウェア構成例を示す図である。図３において、車両２０は、通信装置２１０、情報系サブシステム２２０、制御系サブシステム２３０及び関門器２４０等を含む。
　通信装置２１０は、ネットワークＮ１に接続するための通信モジュールや、他の車両２０又は道路上の機器等と通信するための通信モジュールや、スマートフォン等と無線ＬＡＮ又は近距離無線通信を介して接続するための通信モジュール等を含む。
　情報系サブシステム２２０は、インストールされたプログラムに応じた情報処理を実行する部分であり、ＣＰＵ２２１、メモリ装置２２２、補助記憶装置２２３、表示装置２２４及び入力装置２２５等を含む。補助記憶装置２２３には、インストールされたプログラムや、当該プログラムによって利用される各種データが記憶される。メモリ装置２２２は、起動対象とされたプログラムを補助記憶装置２２３から読み出して格納する。ＣＰＵ２２１は、メモリ装置２２２に格納されたプログラムに従って情報系サブシステム２２０に係る機能を実行する。表示装置２２４はプログラムによるＧＵＩ（Graphical User Interface）等を表示する。入力装置２２５は、ボタン等やタッチパネル等の操作部品であり、様々な操作指示を入力させるために用いられる。なお、例えば、カーナビゲーション、カーオーディオのヘッドユニット等の車載機が情報系サブシステム２２０の一例である。
　制御系サブシステム２３０は、車両２０の挙動を制御する部分であり、各種の制御のための複数のマイコン２３１等を含む。例えば、ＥＣＵ（Electronic Control Unit）がマイコン２３１の一例である。
　関門器２４０は、情報系サブシステム２２０と制御系サブシステム２３０と接続するためのゲートウェイ（例えば、ＣＧＷ（Central Gateway））である。すなわち、情報系サブシステム２２０において扱われる通信プロトコルは、例えば、ＩＰプロトコルであり、制御系サブシステム２３０においてマイコン２３１間の通信に利用される通信プロトコルは、制御に特化した非ＩＰプロトコル（例えば、ＣＡＮ（Controller Area Network））である。したがって、これらの通信プロトコルの違いを吸収するための関門器２４０が設けられる。
　なお、図３に示したハードウェア構成は、一例に過ぎない。後述の機能を実現可能であれば、車両２０のハードウェア構成は特定のものに限定されない。
　図４は、本発明の実施の形態における車両２０及び監視サーバ１０の機能構成例を示す図である。図４において、車両２０の情報系サブシステム２２０は、制御系ログ取得部２５１、センサログ生成部２５２、異常判定部２５３、特徴コンテキスト生成部２５４、ログ送信部２５５及び検知アルゴリズム受信部２５６等を有する。これら各部は、情報系サブシステム２２０にインストールされた１以上のプログラムが、ＣＰＵ２２１に実行させる処理により実現される。情報系サブシステム２２０は、また、制御系ログＤＢ２７１、センサログＤＢ２７２及び検知アルゴリズムＤＢ２７３等のデータベース（記憶部）を有する。これら各データベース（記憶部）は、例えば、メモリ装置２２２又は補助記憶装置２２３等を用いて実現可能である。
　制御系ログ取得部２５１は、制御系ログを取得し、制御系ログＤＢ２７１に保存（記憶）する。制御系ログとは、制御系サブシステム２３０における各マイコン２３１による通信に関するログデータをいう。通信内容のデータ自体が、制御系ログとされてもよい。したがって、制御系ログは、いずれかのマイコン２３１によって通信が行われるたびに発生する。なお、当該通信の内容は、例えば、車両２０の制御、オーディオ、カーナビのようなインフォメント系の情報、車両２０内のインジケータ表示等に関する通信等の内容を示すものである。
　センサログ生成部２５２は、センサログを生成し、センサログＤＢ２７２に保存する。センサログとは、車両２０の各所に配置されているセンサ（例えば、加速度計やＧＰＳ（Global Positioning System）受信機等）から取得されるデータ（例えば、センサによる計測値等）を含むログデータをいう。各センサからのデータの取得及び、当該データに基づくセンサログの生成は、例えば、一定周期、又は特定のイベントの発生等のタイミングにおいて実行される。センサごとにセンサログの生成タイミングは異なっていてもよい。また、センサログが生成されるセンサは、車両２０が有する全センサのうちの一部でもよい。
　異常判定部２５３は、制御系ログ及びセンサログ（以下、それぞれを区別しない場合、単に「ログ」という。）に基づいて、検知アルゴリズムＤＢ２７３に記憶されている検知アルゴリズムを用いて、異常の程度（レベル）を判定する。具体的には、異常判定部２５３は、車両２０から生成されるログの異常の程度を示す指標の値（以下、「異常スコア」という。）を計算する。但し、異常スコアの計算には、制御系ログのみが利用されてもよく、センサログのみが利用されてもよい。計算された異常スコアは制御系ログＤＢ２７１又はセンサログＤＢ２７２に保存される。
　特徴コンテキスト生成部２５４は、ログが取得又は生成されたときの車両２０の外部環境、車両２０の状態等の状況を示す、ログに関連する情報（以下、「特徴コンテキスト」という。）を生成する。例えば、異常スコアが計算されたときに、特徴コンテキスト生成部２５４は、ログが取得又は生成された時間、車両２０の外部環境、車両２０の状態等を表す特徴コンテキストを生成する。特徴コンテキストは、制御系ログＤＢ２７１又はセンサログＤＢ２７２に格納されたログに基づいて生成されてもよく、通信装置２１０から取得された情報に基づいて生成されてもよい。
　ログ送信部２５５は、監視サーバ１０への送信（アップロード）のタイミング（以下「送信タイミング」という。）が到来したときに、制御系ログＤＢ２７１又はセンサログＤＢ２７２に記憶されているログに、特徴コンテキストを付与して監視サーバ１０へ送信する。
　検知アルゴリズム受信部２５６は、監視サーバ１０から配信される検知アルゴリズムの変更要求を受信し、当該変更要求に含まれている検知アルゴリズムによって検知アルゴリズムＤＢ２７３を変更（更新）する。
　一方、監視サーバ１０は、ログ受信部１５１、誤検知・対処方法判断部１５２、検知アルゴリズム変更部１５３、検知アルゴリズム送信部１５４及び対処方法登録部１５５等を有する。これら各部は、監視サーバ１０にインストールされた１以上のプログラムが、ＣＰＵ１０４に実行させる処理により実現される。監視サーバ１０は、また、制御系ログＤＢ１７１、センサログＤＢ１７２、特徴ナレッジＤＢ１７３及び検知アルゴリズムＤＢ１７４等のデータベース（記憶部）を利用する。これら各データベース（記憶部）は、例えば、補助記憶装置１０２、又は監視サーバ１０にネットワークを介して接続可能な記憶装置等を用いて実現可能である。
　ログ受信部１５１は、車両２０から送信（アップロード）されるログを受信し、当該ログを制御系ログＤＢ１７１又はセンサログＤＢ１７２に記憶する。また、ログ受信部１５１は、当該ログの出力元のマイコン２３１又はセンサの識別情報、当該ログの異常スコア及び特徴コンテキスト等を特徴ナレッジＤＢ１７３に記憶する。
　誤検知・対処方法判断部１５２は、ログ受信部１５１において受信したログの異常を分析する。車両２０の異常判定部２５３が異常を検知する場合、誤検知・対処方法判断部１５２は、異常が異常判定部２５３の誤検知によって発生したものであるか否かを判断する。具体的には、誤検知・対処方法判断部１５２は、ログ受信部１５１において受信したログ及び特徴コンテキストの組に一致又は類似する過去のレコードを特徴ナレッジＤＢ１７３から抽出する。なお、過去のレコードは、異なる車両に関するものでもよく、同じ車両に関するもの（異なる時間に得られたもの）でもよい。また、一致又は類似する過去のレコードは、ログのみが一致又は類似するものでもよく、特徴コンテキストのみが一致又は類似するものでもよい。一致又は類似する過去のレコードが既に異常なしと分析されており、特徴ナレッジＤＢ１７３の異常スコアが異常検知閾値未満の値に設定されている場合、誤検知・対処方法判断部１５２は、異常判定部２５３においてログの異常が検知されたとしても、当該異常が異常判定部２５３の過検知によって発生したと判断する。また、誤検知・対処方法判断部１５２は、過検知であると判断すると、検知アルゴリズムの変更を検知アルゴリズム変更部１５３に要求してもよい。
　また、誤検知・対処方法判断部１５２は、受信したログに一致又は類似する過去のレコードに対する対処方法が特徴ナレッジＤＢ１７３に登録されている場合には、当該ログに対しても当該対処方法を実施する。対処方法の例は、誤検知であると扱って特徴ナレッジＤＢ１７３の異常スコアを変更すること、検知アルゴリズムを変更すること等である。一方、一致又は類似する過去のレコードが特徴ナレッジＤＢ１７３に存在しない場合や、対処方法が存在しない場合等には、詳細な分析が必要であるという警告を出力してもよい。
　検知アルゴリズム変更部１５３は、誤検知・対処方法判断部１５２からの要求に応じ、検知アルゴリズムＤＢ１７４に記憶されている一部又は全ての検知アルゴリズムを変更する。なお、検知アルゴリズムＤＢ１７４には、各車両２０に配信されている検知アルゴリズムが記憶されている。
　検知アルゴリズム送信部１５４は、検知アルゴリズム変更部１５３によって変更された検知アルゴリズムを含む変更要求を各車両２０に配信する。
　対処方法登録部１５５は、誤検知・対処方法判断部１５２において詳細な分析が必要であるという警告に対して分析官等により入力された対処方法を特徴ナレッジＤＢ１７３に登録する。
　なお、図４では、異常スコアの計算及び特徴コンテキストの生成が車両２０において行われる例について説明したが、異常スコアの計算又は特徴コンテキストの生成は監視サーバ１０において行われてもよい。また、異常スコア又は特徴コンテキストは分析官等によって手動で入力されてもよい。
　異常スコアの計算が監視サーバ１０において行われる場合、ログ送信部２５５は、送信タイミングが到来したときに、ログを監視サーバ１０へ送信する。監視サーバ１０の異常判定部（図示せず）は、車両２０の異常判定部２５３と同様に異常スコアを計算し、異常スコアを制御系ログＤＢ１７１又はセンサログＤＢ１７２に保存する。
　特徴コンテキストの生成が監視サーバ１０において行われる場合、監視サーバ１０の特徴コンテキスト生成部（図示せず）は、車両２０の特徴コンテキスト生成部２５４と同様に特徴コンテキストを生成し、特徴コンテキストを特徴ナレッジＤＢ１７３に記憶する。特徴コンテキストは、監視サーバ１０の制御系ログＤＢ１７１又はセンサログＤＢ１７２に格納されたログに基づいて生成されてもよく、インタフェース装置１０５を介して取得された情報に基づいて生成されてもよい。
　以下、車両２０の情報系サブシステム２２０が実行する処理手順について説明する。図５は、ログの発生時における処理手順の一例を説明するためのフローチャートである。
　制御系ログ取得部２５１による制御系ログの取得、又はセンサログ生成部２５２によるセンサログの生成等により、制御系ログＤＢ２７１又はセンサログＤＢ２７２にいずれかのログ（以下「対象ログ」という。）が保存される（Ｓ１０１）。
　図６Ａ及び図６Ｂは、ログの構成例を示す図である。図６Ａは、制御系ログの一例を示す。制御系ログは、日時、車両ＩＤ及び要素ＩＤと、Ｄａｔａ［０］、Ｄａｔａ［１］、Ｄａｔａ［２］、Ｄａｔａ［３］、Ｄａｔａ［４］、・・・等（以下、「Ｄａｔａ［］」という。）とを含む。日時は、制御系ログが取得された日時（当該制御系ログに係る通信が行われた日時）である。車両ＩＤは、車両２０の識別情報である。要素ＩＤは、車両２０の構成要素の識別情報である。制御系ログにおける要素ＩＤは、当該制御系ログに係る通信を行ったマイコン２３１の識別情報である。Ｄａｔａ［］は、当該通信に含まれているデータである。例えば、当該通信がエンジンの制御に関する通信であれば、エンジンの制御に関する各パラメータの値が、各Ｄａｔａ［］の値となる。但し、エンジンの制御に関する各パラメータの値のみならず、チェックサムやカウンタ等のデータが、Ｄａｔａ［］に含まれてもよい。
　一方、図６Ｂは、センサログの一例を示す。センサログは、日時、車両ＩＤ及び要素ＩＤと、当該センサログに係るセンサに特有のデータとを含む。日時は、センサログが生成された日時である。車両ＩＤは、車両２０の識別情報である。要素ＩＤは、当該センサログに係るデータの出力元のセンサの識別情報である。また、図６Ｂにおけるセンサログは、加速度センサから取得されたデータに基づくセンサログであるため、加速度センサに特有のデータとして、Ａｃｃ＿Ｘ、Ａｃｃ＿Ｙ及びＡｃｃ＿Ｚを含む。Ａｃｃ＿Ｘ、Ａｃｃ＿Ｙ及びＡｃｃ＿Ｚは、それぞれ、Ｘ軸方向の加速度、Ｙ軸方向の加速度、Ｚ軸方向の加速度である。
　図７は、制御系ログＤＢ２７１の構成例を示す図である。図７に示されるように、制御系ログＤＢ２７１の各レコードは、図６Ａに示した各項目と、異常スコアとを含む。このうち、ステップＳ１０１の時点において、異常スコアの値は空である。異常スコアの値は、ステップＳ１０２において決定されるからである。
　図８は、センサログＤＢ２７２の構成例を示す図である。図８に示されるように、センサログＤＢ２７２の各レコードは、図６Ｂに示した各項目と、異常スコアとを含む。このうち、ステップＳ１０１の時点において、異常スコアの値は、制御系ログＤＢ２７１と同様の理由で空である。なお、センサログの形式は、センサごとに異なる。例えば、ＧＰＳ受信機のセンサログであれば、緯度及び経度等が含まれる。したがって、センサログＤＢ２７２には、センサごと（要素ＩＤごと）に区別されて異なるテーブルにセンサログが記憶されてもよい。
　異常判定部２５３は、対象ログについての異常スコアを判定（計算）し、制御系ログＤＢ２７１又はセンサログＤＢ２７２に保存する（Ｓ１０２）。異常スコアの判定は、一定周期で行われてもよく、特定の値を含むログの発生に応じて行われてもよく、異常の判定に必要な一定量のログが保存されるごとに行われてもよい。
　対象ログについての異常スコアの判定（計算）は、公知技術を用いて行うことができる。例えば、マイコン２３１間の通信間隔や、マイコン２３１が出力したデータ値に基づいて異常スコアが判定されてもよい。また、例えば、ログを入力とし、異常スコアを出力とする学習済みのモデル（例えば、ニューラルネットワーク）に対し、対象ログを入力することで、異常スコアが判定されてもよい。異常スコアは、異常の有無を示す０又は１であってもよいし、異常の程度を最小値（例えば、０）から最大値（例えば、１）の範囲で示す値であってもよい。また、異常スコアの判定は、制御系ログ及びセンサログの双方を用いて行われなくてよい。例えば、制御系ログ及びセンサログのいずれか一方のみが用いられて異常スコアの判定が行われてもよい。
　特徴コンテキスト生成部２５４は、異常判定部２５３において異常スコアが判定されたときに、対象ログについての特徴コンテキストを生成する（Ｓ１０３）。特徴コンテキスト生成部２５４は、対象ログの異常スコアが異常検知閾値以上である場合、すなわち、異常と検知された場合に特徴コンテキストを生成するだけでなく、対象ログの異常スコアが異常検知閾値未満である場合、すなわち、正常と検知された場合にも特徴コンテキストを生成してもよい。
　特徴コンテキスト生成部２５４は、車両２０の外部環境を示す空間的特徴コンテキスト、ログが取得又は生成された時間を示す時間的特徴コンテキスト、車両２０の挙動を示す挙動的特徴コンテキスト等を生成する。また、車両２０の交通状況に関する情報を示す交通ドメイン依存コンテキスト、車両２０の状態に関する情報を示す車両ドメイン依存コンテキスト等が生成されてもよい。
　空間的特徴コンテキストの例は、天候、場所、障害物、気温、雨量、湿度、気圧、風速等である。時間的特徴コンテキストの例は、時間、曜日、季節、イベント等である。挙動的特徴コンテキストの例は、車両２０のセンサ又は他の車両のセンサ等から取得される速度、加速度、角速度等である。交通ドメイン依存コンテキストの例は、走行経路、路面状況、交通流量、勾配、標高、幅員、車線等である。車両ドメイン依存コンテキストの例は、車種、年式、オプションの有無、故障履歴、搭載ＥＣＵ、攻撃履歴、攻撃キャンペーン情報等である。なお、これらの特徴コンテキストの分類は単なる便宜上のものであり、例えば、気温、雨量、湿度、気圧、風速等が時間的特徴コンテキストに分類されてもよく、勾配、標高等が空間的特徴コンテキストに分類されてもよい。また、上記の特徴コンテキストの任意の組み合わせが用いられてもよく、他の特徴コンテキストが用いられてもよい。
　例えば、スマートフォンや外部のサーバ等から通信装置２１０を介して天候、気温等の情報が取得できる場合、特徴コンテキスト生成部２５４は、気象環境を表す空間的特徴コンテキストを生成する。例えば、特徴コンテキスト生成部２５４は、センサログＤＢ２７２に保存されているＧＰＳ受信機のセンサログから、車両２０の場所を表す空間的特徴コンテキストを生成する。例えば、特徴コンテキスト生成部２５４は、センサログＤＢ２７２に保存されているＧＰＳ受信機のセンサログと、制御系ログＤＢ２７１に保存されている車速の制御系ログとを用いて、車両２０の速度及び加速度を表す挙動的特徴コンテキストを生成する。それぞれの特徴コンテキストは瞬間値として生成されてもよく、或る期間内の連続値又は離散値として生成されてもよい。
　ログ送信部２５５は、送信タイミングが到来したときに、対象ログに、特徴コンテキストを付与して監視サーバ１０へ送信する（Ｓ１０４）。ログ送信部２５５は、異常と検知されたログ（すなわち、異常スコアが異常検知閾値以上のログ）及び正常と検知されたログ（すなわち、異常スコアが異常検知閾値未満のログ）の双方を監視サーバ１０へ送信してもよく、異常と検知されたログを送信し、正常と検知されたログを送信しなくてもよい。また、ログ送信部２５５は、予め設定された優先度又は基準に基づいて、送信すべきログを選択してもよい。
　なお、異常スコアの判定（Ｓ１０２）及び特徴コンテキストの生成（Ｓ１０３）は、監視サーバ１０が対象ログを受信した後に監視サーバ１０が実行してもよい。
　以下、監視サーバ１０が実行する処理手順について説明する。図９は、ログの受信時における処理手順の一例を説明するためのフローチャートである。
　ログ受信部１５１は、対象ログを特徴コンテキストと共に受信し、対象ログを制御系ログＤＢ１７１又はセンサログＤＢ１７２に保存し、特徴コンテキストを特徴ナレッジＤＢ１７３に保存する（Ｓ２０１）。制御系ログＤＢ１７１及びセンサログＤＢ１７２は、それぞれ図７及び図８と同様に構成される。
　図１０は、特徴ナレッジＤＢ１７３の構成例を示す図である。図１０に示されるように、特徴ナレッジＤＢ１７３の各レコードは、制御系ログＤＢ１７１又はセンサログＤＢ１７２の中の日時、車両ＩＤ、要素ＩＤ及び異常スコアに加えて、特徴コンテキスト及び対処方法を含む。特徴コンテキストには、ログ受信部１５１が受信した特徴コンテキストが保存される。対処方法は、ステップＳ３０３において登録されるため、空である。車両ＩＤ及び要素ＩＤの組み合わせによって、対象ログの出力元の車両２０及びマイコン２３１又はセンサが識別できる。なお、特徴ナレッジＤＢ１７３のレコードと、制御系ログＤＢ１７１又はセンサログＤＢ１７２のレコードとの対応関係は、日時と車両ＩＤと要素ＩＤとの組によって識別されてもよく、制御系ログＤＢ１７１又はセンサログＤＢ１７２のレコードを示すログＩＤを特徴ナレッジＤＢ１７３に追加することによって識別されてもよい。
　異常スコアが異常検知閾値以上である場合（Ｓ２０２：Ｙｅｓ）、以下の処理が実行される。なお、車両２０のログ送信部２５５が、異常スコアが異常検知閾値未満であるログを送信しない場合には、ステップＳ２０２は実施されなくてもよい。
　誤検知・対処方法判断部１５２は、対象ログ又は特徴コンテキストと、特徴ナレッジＤＢ１７３に保存されている過去のレコードとの類似度を判定（計算）する（Ｓ２０３）。特徴コンテキストが連続値として生成されている場合には、類似度の判定のために連続値が離散値に変換されてもよい。
　一致又は類似の判定方法は、公知技術を用いて行うことができる。例えば、完全一致又は部分一致が用いられてもよい。また、例えば、様々なログ及び特徴コンテキストを入力とし、それぞれの類似度を出力とする学習済みのモデル（例えば、ニューラルネットワーク）に対し、対象ログ及び特徴コンテキストと、特徴ナレッジＤＢ１７３内のいずれかのレコードとを入力することで、類似度が判定されてもよい。その他に、外れ値検定等の統計処理が行われてもよい。特徴コンテキストの一致又は類似の判定は、複数の特徴コンテキストにまたがって行われてもよい。複数のコンテキストにまたがって判定が行われる場合、特徴コンテキストに応じた重みが適用されてもよい。
　一致又は類似する過去のレコードが特徴ナレッジＤＢ１７３に存在する場合（Ｓ２０４：Ｙｅｓ）、且つ、当該レコードに対して自動的に実施可能な対処方法が特徴ナレッジＤＢ１７３に存在する場合（Ｓ２０５：Ｙｅｓ）、誤検知・対処方法判断部１５２は、当該対処方法を実施する（Ｓ２０６）。
　例えば、車両２０のブレーキの制御を担うマイコン２３１が閾値を超えて稼働していると異常判定部２５３が判定した結果、当該マイコン２３１の制御系ログからブレーキの挙動を示す挙動的特徴コンテキストが生成され、ＧＰＳ受信機のセンサログ、カメラ又は距離センサのセンサログ、ＶＩＣＳ（登録商標）（Vehicle Information and Communication System）情報、Ｖ２Ｖ（Vehicle-to-Vehicle）又はＶ２Ｉ（Vehicle-to-Infrastructure）によって得られる情報から、車両２０の場所を示す空間的特徴コンテキストと、渋滞の発生を示す交通ドメイン依存コンテキストが生成されたと仮定する。車両２０の状態を示す車両ドメイン依存コンテキスト等の他の特徴コンテキストも生成されるが、ブレーキの制御に関係する特徴コンテキストに高い重みが適用される。重みは、誤検知を含む異常の判定において特徴コンテキストに加味される係数であり、例えば、特徴コンテキストに対する対数係数のような形で実装されてもよい。ここでは、挙動的特徴コンテキスト、空間的特徴コンテキスト及び交通ドメイン依存コンテキストの類似度に着目するため、これらの特徴コンテキストに高い重みが適用される。誤検知・対処方法判断部１５２は、一致又は類似する過去のレコードを特徴ナレッジＤＢ１７３から検索する。一致又は類似する過去のレコードの異常スコアが異常検知閾値未満である場合、誤検知・対処方法判断部１５２は、渋滞によって誤検知が発生したと判断し、特徴ナレッジＤＢ１７３において当該マイコン２３１の制御系ログに関する異常スコアの値を更新する。また、一致又は類似する過去のレコードに対して自動的に実施可能な対処方法が設定されている場合、誤検知・対処方法判断部１５２は、当該対処方法を実施する。
　例えば、車両２０のワイパーの制御を担うマイコン２３１が閾値を超えて稼働していると異常判定部２５３が判定した結果、当該マイコン２３１の制御系ログからワイパーの挙動を示す挙動的特徴コンテキストが生成され、外部のサーバから天候が雨天であることを示す空間的特徴コンテキストが生成され、車種を示す車両ドメイン依存コンテキストが生成されたと仮定する。ここでは、ワイパーの制御に関して挙動的特徴コンテキスト、空間的特徴コンテキスト及び車両ドメイン依存コンテキストの類似度に着目するため、これらの特徴コンテキストに高い重みが適用される。誤検知・対処方法判断部１５２は、一致又は類似する過去のレコードを特徴ナレッジＤＢ１７３から検索する。一致又は類似する過去のレコードの異常スコアが異常検知閾値未満である場合、誤検知・対処方法判断部１５２は、ワイパーの異常を判定するための閾値が適正でないことによって誤検知が発生したと判断し、特徴ナレッジＤＢ１７３において当該マイコン２３１の制御系ログに関する異常スコアの値を更新する。また、一致又は類似する過去のレコードに対して自動的に実施可能な対処方法が設定されている場合、誤検知・対処方法判断部１５２は、当該対処方法を実施する。
　一方、一致又は類似する過去のレコードが特徴ナレッジＤＢ１７３に存在しない場合（Ｓ２０４：Ｎｏ）、又は、当該レコードに対して自動的に実施可能な対処方法が特徴ナレッジＤＢ１７３に存在しない場合（Ｓ２０５：Ｎｏ）、誤検知・対処方法判断部１５２は、未知の検知であるため詳細な分析が必要であるという警告を出力する（Ｓ２０７）。警告は、監視サーバ１０から他の分析器又は分析官等に通知されてもよい。
　上記のブレーキの制御を担うマイコン２３１の異常検知の例、又はワイパーの制御を担うマイコン２３１の異常検知の例において、誤検知・対処方法判断部１５２は、誤検知であるかを判断できない場合、詳細な分析を他の分析器又は分析官等に要求する。
　他の分析器又は分析官等は、制御系ログＤＢ１７１又はセンサログＤＢ１７２に保存されているログと、特徴ナレッジＤＢ１７３に保存されている特徴コンテキストとを参照して、異常の分析を行う。ログに特徴コンテキストが付与されているため、サイバー攻撃等の大規模な異常（複数の車両２０に跨る異常）の発生の可能性の有無も判定できる。斯かる異常の分析方法は、所定の方法に限定されない。例えば、学習済みのモデル（ニューラルネットワーク等）に基づいて行われてもよいし、他の公知技術を用いて行われてもよい。また、異常の発生の可能性の有無の判定には、自動車会社のＣＥＲＴ（Computer Emergency Response Team）、別の企業が有するＳＯＣ（Security Operation Center）、セキュリティベンダからの発表等の情報が利用されてもよい。
　他の分析器又は分析官等の分析結果に応じて対処方法が決定される。例えば、誤検知であると判断されたログに対しては、異常として検知されなくするように検知アルゴリズムを変更する対処方法が決定される。例えば、誤検知でないと判断されたログに対しては、故障箇所の点検又は修理、マイコン２３１や補助記憶装置２２３等のソフトウェアの更新等の対処方法が決定される。
　以下、他の分析器又は分析官等による分析が終了した後に、監視サーバ１０が実行する処理手順について説明する。図１１は、対処方法の決定時における処理手順の一例を説明するためのフローチャートである。
　対処方法登録部１５５は、他の分析器又は分析官等により決定された対処方法を受け取る（Ｓ３０１）。対処方法には、自動的に実施可能な対処方法と、ディーラーでの点検又は修理等が必要であり自動的に実施不可能な対処方法が存在する。自動的に実施可能な対処方法には、例えば、異常判定部２５３が用いる検知アルゴリズムを変更すること、誤検知として扱うこと、車両２０の所有者等の予め設定された連絡先に通知すること等が含まれる。
　対処方法登録部１５５は、自動的に実施可能な対処方法を受け取った場合（Ｓ３０２：Ｙｅｓ）、当該対処方法を特徴ナレッジＤＢ１７３に登録する（Ｓ３０３）。なお、自動的に実施不可能な対処方法についても、自動的に実施不可能であるという内容を特徴ナレッジＤＢ１７３に登録してもよい。
　また、検知アルゴリズムを変更するという対処方法が特徴ナレッジＤＢ１７３に登録された場合（Ｓ３０４：Ｙｅｓ）、誤検知・対処方法判断部１５２は、検知アルゴリズムの変更を検知アルゴリズム変更部１５３に要求し、検知アルゴリズム変更部１５３は、検知アルゴリズムＤＢ１７４に記憶されている検知アルゴリズムを変更する（Ｓ３０５）。検知アルゴリズムの変更には、異常判定部２５３が用いる特徴量の抽出方法の変更、特徴量に対する重みの変更、閾値の調節、異常と判定しない条件を示すホワイトリストの設定等が含まれる。
　検知アルゴリズム送信部１５４は、無線等のインタフェース装置１５０を介して検知アルゴリズムを車両２０に送信する（Ｓ３０６）。検知アルゴリズムの送信は、一定周期で行われてもよく、検知アルゴリズムの変更に応じて行われてもよい。なお、検知アルゴリズム送信部１５４は、検知アルゴリズムの更新が必要であることを車両２０の所有者等の予め設定された連絡先に通知し、車両２０における検知アルゴリズムの更新は、ディーラー等で行われてもよい。車両２０の検知アルゴリズム受信部２５６は、検知アルゴリズムを受信し、検知アルゴリズムＤＢ２７３を変更する。変更された検知アルゴリズムは、図５のステップＳ１０２において異常スコアを判定するために用いられる。
　このように、本実施の形態では、ログに特徴コンテキストが付与されるため、異常が検知された状態を把握することが容易になる。その結果、検知結果の正誤判定や意味づけ等の分析に要するコストが低減できる。また、誤検知であるという判断に応じて検知アルゴリズムを更新することで、誤検知の発生を低減できる。
　なお、本実施の形態では、車両２０を機器の一例として説明したが、通信機能を有する他の機器について本実施の形態が適用されてもよい。例えば、工場におけるロボット等の産業用制御機器、各地に配置されたセンサ、オーディオ機器、家電製品、通信端末（スマートフォン、タブレット端末等）や、一般的にＩｏＴ（Internet of Things）機器と呼ばれる機器について、本実施の形態が適用されてもよい。
　上述したように、本実施の形態によれば、車両２０において発生するデータ（ログ）に対して特徴コンテキストが付与されて監視サーバ１０へ送信される。監視サーバ１０は、送信されたログ及び特徴コンテキストを紐付けて特徴ナレッジＤＢ１７３に保存することにより、ログの分析に要するコストを低減することができる。
　また、監視サーバ１０は、自動的に実施可能な対処方法を特徴ナレッジＤＢ１７３に登録することにより、分析官等が分析すべきログの量を減少させることができる。
　また、監視サーバ１０は、過検知が発生したときに、当該過検知が発生しないように車両２０の検知アルゴリズムを変更することで、過検知の発生を低減することができる。
　なお、本実施の形態において、車両２０は、機器の一例である。監視サーバ１０は、情報処理装置の一例である。ログ受信部１５１は、記憶処理部の一例である。誤検知・対処方法判断部１５２は、分析部の一例である。対処方法登録部１５５は、登録部の一例である。検知アルゴリズム変更部１５３及び検知アルゴリズム送信部１５４は、変更部の一例である。
　以上、本発明の実施の形態について詳述したが、本発明は斯かる特定の実施形態に限定されるものではなく、請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。
　本国際出願は２０１８年１０月１１日に出願した日本国特許出願２０１８－１９２４１５号に基づく優先権を主張するものであり、２０１８－１９２４１５号の全内容を本国際出願に援用する。
１０　　　　　監視サーバ
２０　　　　　車両
３０ａ　　　　サービス提供サーバ
３０ｂ　　　　サービス提供サーバ
１００　　　　ドライブ装置
１０１　　　　記録媒体
１０２　　　　補助記憶装置
１０３　　　　メモリ装置
１０４　　　　ＣＰＵ
１０５　　　　インタフェース装置
１５１　　　　ログ受信部
１５２　　　　誤検知・対処方法判断部
１５３　　　　検知アルゴリズム変更部
１５４　　　　検知アルゴリズム送信部
１５５　　　　対処方法登録部
１７１　　　　制御系ログＤＢ
１７２　　　　センサログＤＢ
１７３　　　　特徴ナレッジＤＢ
１７４　　　　検知アルゴリズムＤＢ
２１０　　　　通信装置
２２１　　　　ＣＰＵ
２２２　　　　メモリ装置
２２３　　　　補助記憶装置
２２４　　　　表示装置
２２５　　　　入力装置
２２０　　　　情報系サブシステム
２３０　　　　制御系サブシステム
２３１　　　　マイコン
２４０　　　　関門器
２５１　　　　制御系ログ取得部
２５２　　　　センサログ生成部
２５３　　　　異常判定部
２５４　　　　特徴コンテキスト生成部
２５５　　　　ログ送信部
２５６　　　　検知アルゴリズム受信部
２７１　　　　制御系ログＤＢ
２７２　　　　センサログＤＢ
２７３　　　　検知アルゴリズムＤＢ
Ｂ　　　　　　バス

Claims (8)

  1. 　１つ又は複数の機器のうちいずれかの機器が出力した第１のデータを、当該第１のデータに関連する第１の特徴コンテキストと対応付けて記憶部に格納する記憶処理部と、
    　１つ又は複数の機器のうちいずれかの機器から第２のデータを受信した場合、当該第２のデータに関連する第２の特徴コンテキストを取得し、当該受信した第２のデータ及び当該取得した第２の特徴コンテキストと、前記記憶部に格納された第１のデータ及び第１の特徴コンテキストとに基づいて、当該受信した第２のデータの異常を分析する分析部と、
    　を有する情報処理装置。
  2. 　前記第１のデータに対して実施すべき対処方法を、前記第１のデータ又は前記第１の特徴コンテキストと対応付けて前記記憶部に登録する登録部を更に有する、請求項１に記載の情報処理装置。
  3. 　前記分析部は、前記記憶部から、前記受信した第２のデータに一致又は類似するデータ、又は前記取得した第２の特徴コンテキストに一致又は類似する特徴コンテキストを抽出し、当該抽出されたデータ又は特徴コンテキストに対する対処方法を出力する、請求項２に記載の情報処理装置。
  4. 　前記分析部における分析結果に基づいて、前記第２のデータを出力した機器の検知アルゴリズムを変更する変更部を更に有する、請求項１乃至３のうちいずれか１項に記載の情報処理装置。
  5. 　前記第１の特徴コンテキスト及び前記第２の特徴コンテキストは、機器の外部環境を示す空間的特徴コンテキスト、機器がデータを出力した時間を示す時間的特徴コンテキスト、及び機器の挙動を示す挙動的特徴コンテキストのうち少なくとも１つを含む、請求項１乃至４のうちいずれか１項に記載の情報処理装置。
  6. 　前記分析部は、特徴コンテキストに応じた重みを適用する、請求項１乃至５のうちいずれか１項に記載の情報処理装置。
  7. 　情報処理装置が、
    　１つ又は複数の機器のうちいずれかの機器が出力した第１のデータを、当該第１のデータに関連する第１の特徴コンテキストと対応付けて記憶部に格納する記憶処理手順と、
    　１つ又は複数の機器のうちいずれかの機器から第２のデータを受信した場合、当該第２のデータに関連する第２の特徴コンテキストを取得し、当該受信した第２のデータ及び当該取得した第２の特徴コンテキストと、前記記憶部に格納された第１のデータ及び第１の特徴コンテキストとに基づいて、当該受信した第２のデータの異常を分析する分析手順と、
    　を実行する異常分析方法。
  8. 　請求項１乃至６のうちいずれか１項に記載の各部として情報処理装置を機能させるためのプログラム。
PCT/JP2019/040017 2018-10-11 2019-10-10 情報処理装置、異常分析方法及びプログラム WO2020075801A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
EP19871518.7A EP3842944A4 (en) 2018-10-11 2019-10-10 INFORMATION PROCESSING DEVICE, ANOMALITY ANALYSIS METHOD AND PROGRAM
CN201980064266.3A CN112805687A (zh) 2018-10-11 2019-10-10 信息处理装置、异常分析方法以及程序
US17/280,823 US11863574B2 (en) 2018-10-11 2019-10-10 Information processing apparatus, anomaly analysis method and program
JP2020551221A JP7180686B2 (ja) 2018-10-11 2019-10-10 情報処理装置、異常分析方法及びプログラム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2018-192415 2018-10-11
JP2018192415 2018-10-11

Publications (1)

Publication Number Publication Date
WO2020075801A1 true WO2020075801A1 (ja) 2020-04-16

Family

ID=70163825

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/040017 WO2020075801A1 (ja) 2018-10-11 2019-10-10 情報処理装置、異常分析方法及びプログラム

Country Status (5)

Country Link
US (1) US11863574B2 (ja)
EP (1) EP3842944A4 (ja)
JP (1) JP7180686B2 (ja)
CN (1) CN112805687A (ja)
WO (1) WO2020075801A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023048187A1 (ja) * 2021-09-24 2023-03-30 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
WO2023170995A1 (ja) * 2022-03-10 2023-09-14 日立Astemo株式会社 車両診断システム

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7380473B2 (ja) * 2020-07-29 2023-11-15 株式会社デンソー セキュリティ監視システム

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011034208A (ja) * 2009-07-30 2011-02-17 Hitachi Ltd 異常検出方法、装置、及びプログラム
JP2015136107A (ja) * 2014-01-06 2015-07-27 アーガス サイバー セキュリティ リミテッド グローバル自動車安全システム
US20160381066A1 (en) * 2015-06-29 2016-12-29 Argus Cyber Security Ltd. System and method for content based anomaly detection in an in-vehicle communication network
JP2017111796A (ja) * 2015-12-16 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
JP2018192415A (ja) 2017-05-16 2018-12-06 王子ホールディングス株式会社 塗工装置、および、衛生用品の製造装置

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090024880A1 (en) * 2007-07-18 2009-01-22 Udo Klein System and method for triggering control over abnormal program termination
US9009796B2 (en) * 2010-11-18 2015-04-14 The Boeing Company Spot beam based authentication
CN103067344B (zh) * 2011-10-24 2016-03-30 国际商业机器公司 在云环境中自动分发安全规则的非侵入性方法和设备
CN104901976A (zh) * 2014-03-03 2015-09-09 华为技术有限公司 一种车辆内部使用场景的设置方法、车载设备和网络设备
US9584532B2 (en) 2014-10-31 2017-02-28 Ncr Corporation Enterprise intrusion detection and remediation
US20180365124A1 (en) 2015-12-14 2018-12-20 Nec Corporation Log analysis system, log analysis method, and log analysis program

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011034208A (ja) * 2009-07-30 2011-02-17 Hitachi Ltd 異常検出方法、装置、及びプログラム
JP2015136107A (ja) * 2014-01-06 2015-07-27 アーガス サイバー セキュリティ リミテッド グローバル自動車安全システム
US20160381066A1 (en) * 2015-06-29 2016-12-29 Argus Cyber Security Ltd. System and method for content based anomaly detection in an in-vehicle communication network
JP2017111796A (ja) * 2015-12-16 2017-06-22 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカＰａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ セキュリティ処理方法及びサーバ
JP2018192415A (ja) 2017-05-16 2018-12-06 王子ホールディングス株式会社 塗工装置、および、衛生用品の製造装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
PANASONIC DEVELOP AUTOMOTIVE INTRUSION DETECTION AND PREVENTION SYSTEMS AGAINST CYBER ATTACKS, Retrieved from the Internet <URL:https://news.panasonic.com/jp/press/data/2017/10/jn171010-2/jn171010-2.html>
See also references of EP3842944A4

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2023048187A1 (ja) * 2021-09-24 2023-03-30 エヌ・ティ・ティ・コミュニケーションズ株式会社 車両セキュリティ分析装置、方法およびそのプログラム
WO2023170995A1 (ja) * 2022-03-10 2023-09-14 日立Astemo株式会社 車両診断システム

Also Published As

Publication number Publication date
US20210409434A1 (en) 2021-12-30
EP3842944A1 (en) 2021-06-30
US11863574B2 (en) 2024-01-02
JPWO2020075801A1 (ja) 2021-09-02
JP7180686B2 (ja) 2022-11-30
CN112805687A (zh) 2021-05-14
EP3842944A4 (en) 2022-04-27

Similar Documents

Publication Publication Date Title
US11380197B2 (en) Data analysis apparatus
US11363045B2 (en) Vehicle anomaly detection server, vehicle anomaly detection system, and vehicle anomaly detection method
JP7056752B2 (ja) 分析装置、分析システム、分析方法及びプログラム
US20210344700A1 (en) Vehicle security monitoring apparatus, method and non-transitory computer readable medium
US11528325B2 (en) Prioritizing data using rules for transmission over network
WO2020075809A1 (ja) 情報処理装置、データ分析方法及びプログラム
US11178164B2 (en) Data analysis apparatus
WO2020075801A1 (ja) 情報処理装置、異常分析方法及びプログラム
CN110494330A (zh) 车辆监视装置、不正当检测服务器、以及控制方法
JP2018144800A (ja) 連携クラウド・エッジ車両異常検出
US11539724B2 (en) Centralized detection techniques for cyber-attacks directed at connected vehicles
CN110325410B (zh) 数据分析装置及存储介质
EP4158918B1 (en) Method and system for assessing the correctness of information transmitted by a vehicle
US20230206751A1 (en) Method and system for assessing the correctness of information transmitted by a vehicle

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020551221

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2019871518

Country of ref document: EP

Effective date: 20210323

NENP Non-entry into the national phase

Ref country code: DE