JP6041727B2 - Management apparatus, management method, and management program - Google Patents

Description

  The present invention relates to a management device, a management method, and a management program.

  In a monitoring system that monitors the status of a customer system via a network, in addition to the content of the failure, incidental information such as messages and log information is notified to the maintenance center when a failure occurs in the customer system. The maintenance center attempts to resolve the failure early by troubleshooting the failure content based on the incidental information.

  In the maintenance center, for example, at the timing of hardware shipment, software commercialization, etc., a white list in which a normal system configuration guaranteed by the manufacturer of the customer system is registered, or a fault system known by the manufacturer Manage blacklists that have registered configurations. Then, the maintenance center refers to the white list or black list, and determines the presence or absence of a failure by comparing with the system configuration collected from the customer system.

JP 2009-230457 A

“Systemwalker IT Change Manager V14g Product Catalog”, [online], March 19, 2013 search, Internet <URL: http://systemwalker.fujitsu.com/jp/catalog/pdf/changemanager/changemanager-p.pdf>

  However, in the above technique, when configuration information is newly registered in the black list, there is a problem that a time lag or an oversight occurs in the detection of the system having the configuration information, and the risk of system abnormality cannot be detected at an early stage. .

  For example, when a security hole or the like is found in the configuration information registered in the white list, the maintenance center moves the configuration information from the white list to the black list. Thereafter, the maintenance center cannot detect the risk of failure of the system until new configuration information is received from the system having the configuration information.

  Further, the maintenance center may compare with each list when the configuration information received from the system has been changed from the configuration information received last time in order to reduce the processing load. In this case, the maintenance center does not compare the configuration information received from the system with the list until the configuration information is changed in the system having the configuration information newly registered in the black list. Therefore, the maintenance center cannot detect the risk of failure of the system until the configuration information of the system is changed.

  An object of one aspect is to provide a management device, a management method, and a management program that can detect the risk of system abnormality at an early stage.

  In the first plan, the management device includes a storage unit that stores configuration information received from the electronic device, and a first list that stores configuration information indicating that the electronic device is in the first state. When receiving the configuration information of the electronic device, the management device determines whether the configuration information is different from the configuration information received earlier based on the storage unit, and if different, stores the configuration information in the first list. It has a determination part which determines whether it is the same as the configured information. The management device includes a detection unit that detects, from the storage unit, an electronic device corresponding to the configuration information when the determination unit determines that the configuration information is the same as the configuration information stored in the first list. .

  In one embodiment of the present application, the risk of system abnormality can be detected early.

FIG. 1 is an explanatory diagram illustrating an example of the monitoring system according to the embodiment. FIG. 2 is a block diagram showing the configuration of the customer system. FIG. 3 is an explanatory diagram illustrating an example of the configuration information. FIG. 4 is a block diagram illustrating a configuration of each device included in the monitoring center. FIG. 5 is an explanatory diagram schematically showing an example of a table configuration of a big DB. FIG. 6 is an explanatory diagram illustrating an example of a table configuration of the storage DB. FIG. 7 is an explanatory diagram illustrating an example of a failure determination process executed by the CPU in the server. FIG. 8 is an explanatory diagram showing an example of a list update process executed by the CPU in the server. FIG. 9 is an explanatory diagram illustrating an example of a list determination process executed by the CPU in the server. FIG. 10 is a flowchart illustrating an example of the processing operation of the CPU in the server related to the configuration change check process. FIG. 11 is a flowchart illustrating an example of a processing operation of the CPU in the server related to the failure determination process. FIG. 12 is a flowchart illustrating an example of the processing operation of the CPU in the server related to the unknown list determination process. FIG. 13 is a flowchart showing an example of the processing operation of the CPU in the server related to the yellow list determination process. FIG. 14 is a flowchart illustrating an example of the processing operation of the CPU in the server related to the verified list determination process. FIG. 15 is a flowchart illustrating an example of the processing operation of the CPU in the server related to the list determination process. FIG. 16 is a flowchart illustrating an example of the processing operation of the CPU in the server related to the danger notification process.

  Embodiments of a management device, a management method, and a management program disclosed in the present application will be described below in detail with reference to the drawings. Note that the present invention is not limited to the embodiments.

[overall structure]
FIG. 1 is an explanatory diagram illustrating an example of the monitoring system according to the embodiment. A monitoring system 1 shown in FIG. 1 includes a plurality of customer systems 2, a monitoring center 3, a manufacturer side device 100, and a maintenance terminal 400. For example, the monitoring center 3 remotely monitors the states of a plurality of customer systems 2 at remote locations. As shown in FIG. 4, the monitoring center 3 includes a server 4, a database (hereinafter sometimes simply referred to as DB) device 5, and a failure monitoring device 6. Each customer system 2 is a customer system monitored by the monitoring center 3.

  The monitoring center 3 and each customer system 2 are connected via an external network 200 such as the Internet. Similarly, the monitoring center 3 and the manufacturer side device 100 are connected via an external network 200 such as the Internet. Note that the manufacturer-side device 100 is a manufacturer of electronic devices constituting the customer system, and notifies the monitoring center 3 of relevant configuration information when a security hole or the like of each electronic device is found.

  The monitoring center 3 and each maintenance terminal 400 are connected via an in-house network 300 such as an intranet. The maintenance terminal 400 is a terminal used by a maintenance person who maintains each customer system 2 or the like, or a terminal used by a supervisor who monitors the customer system 2 at the monitoring center 3.

[Customer system configuration]
FIG. 2 is a block diagram showing the configuration of the customer system. For example, the customer system 2 is configured by an electronic device such as a computer device. As shown in FIG. 2, the customer system 2 includes a communication interface (hereinafter sometimes simply referred to as IF) 11, a display unit 12, an operation unit 13, and a TPM (Trusted Platform Module) chip 14. Further, the customer system 2 includes an HDD (Hard Disk Drive) 15, a RAM (Random Access Memory) 16, a CPU (Control Processing Unit) 17, and a bus 18.

  The communication IF 11 is an IF that manages communication with the server 4. The display unit 12 is an output IF that displays various types of information. The operation unit 13 is an input IF for inputting various information. The HDD 15 is a non-volatile storage area that stores various types of information. The RAM 16 is a volatile storage area that stores various types of information. The CPU 17 controls the customer system 2 as a whole. The bus 18 is a transmission path for transmitting data among the communication IF 11, the display unit 12, the operation unit 13, the TPM chip 14, the HDD 15, the RAM 16, and the CPU 17.

  Here, the characteristics of the TPM chip 14 will be described. The TPM chip 14 is a chip that employs TCG (Trusted Computing Group) technology. In recent years, devices connected to the Internet have always been exposed to security threats, and there is a risk that viruses, spyware, other malicious scripts, unauthorized access, etc. will cause unexpected changes to the software structure that constitutes the platform. is there. TCG technology realizes a secure computing environment by guaranteeing platform reliability. The platform is, for example, hardware, an OS (Operating System), an application, or the like. For example, with respect to the threat of software tampering, there are limits to conventional security measures that rely only on software. Therefore, in the TCG technology, a TPM chip 14 is embedded in a platform, and the TPM chip 14 is used as a root of trust to construct a highly reliable computing environment that is difficult to falsify. Further, in the TCG technology, the TPM chip 14 is used to realize hardware-based data and certificate protection and secure encryption processing.

  The TPM chip 14 is a chip having tamper resistance, and is physically mounted on a main component part of the electronic device such as a mother board so that it cannot be detached from the electronic device. The functions of the TPM chip 14 include a RSA (Rivest Shamir Adleman) private key / public key pair generation / storage function, and an RSA private key signature, encryption, and decryption function. The functions of the TPM chip 14 include a function for calculating a hash value of SHA-1 (Secure Hash Algorithm 1), a function for holding environment information of an electronic device, and the like.

  TCG defines a software stack and a software interface in order to use a TPM chip as a hardware device from a higher-level application or library. The software stack is called TSS (TCG Software Stack) and is composed of software modules that store the functions of the TPM chip 14 with limited resources. Further, the CPU application in the electronic device accesses the function of the TPM chip 14 using an interface provided by the TSS.

  Further, the TPM chip 14 acquires software code in the boot process to the BIOS (Basic Input / Output System), the OSloader, and the OS kernel when the CPU of the electronic device is activated. The TPM chip 14 hashes the acquired software code to obtain a hash value having a software configuration. Then, the TPM chip 14 registers the hash value of the software configuration in a register inside the TPM chip 14. Further, the TPM chip 14 acquires information on the hardware configuration of the electronic device, and hashes the hardware configuration information to obtain a hash value of the hardware configuration. Then, the TPM chip 14 registers the hash value of the hardware configuration in a register inside the TPM chip 14. That is, the TPM chip 14 registers the hash value of the software configuration and the hardware configuration of the electronic device in the register.

  FIG. 3 is an explanatory diagram illustrating an example of the configuration information. Software information, software setting values, OS information, OS setting values, and the like shown in FIG. 3 are software codes of the customer system 2. The hardware information is hardware information of the customer system 2. The TPM chip 14 hashes the software information to obtain a hash value A1. The TPM chip 14 hashes the software setting value to obtain the hash value A2. The TPM chip 14 hashes the OS information to obtain a hash value A3. The TPM chip 14 hashes the OS setting value to obtain a hash value A4. The TPM chip 14 hashes the hardware information to obtain a hash value A5. Further, the TPM chip 14 hashes the software information hash value A1, the software setting value hash value A2, the OS information hash value A3, the OS setting value hash value A4, and the hardware information hash value A5 to represent the hash value. The value A is obtained. The configuration information includes software configuration hash values A1, A2, A3, and A4 and / or hardware configuration hash value A5, and representative hash value A.

  The CPU 17 of the customer system 2 acquires the configuration information obtained by the TPM chip 14 from the certificate authority for the public key of the TPM chip 24 on the server 4 side, and encrypts the configuration information using the acquired public key. Further, the CPU 17 transmits the encrypted configuration information to the server 4 through the communication IF 11. Further, the CPU 27 of the server 4 receives configuration information from the customer system 2 through the communication IF 21. Then, the TPM chip 24 in the server 4 decrypts the configuration information of the customer system 2 received with the private key held by itself. The customer system 2 transmits information such as a system ID and a location ID for identifying the customer system 2 to the server 4 in addition to the configuration information.

[Configuration of monitoring center]
FIG. 4 is a block diagram illustrating a configuration of each device included in the monitoring center. As shown in FIG. 4, the monitoring center 3 includes a server 4, a DB device 5, and a failure monitoring device 6.

(Server configuration)
The server 4 is, for example, a computer device. As illustrated in FIG. 4, the server 4 includes a communication IF 21, a display unit 22, an operation unit 23, a TPM chip 24, an HDD 25, a RAM 26, a CPU 27, and a bus 28.

  The communication IF 21 is an IF that manages communication with the customer system 2. The display unit 22 is an output IF that displays various types of information. The operation unit 23 is an input IF for inputting various information. The HDD 25 is a non-volatile storage area that stores various types of information. The RAM 26 is a volatile storage area that stores various types of information. The CPU 27 controls the entire server 4. The bus 28 is a transmission path for transmitting data among the communication IF 21, the display unit 22, the operation unit 23, the TPM chip 24, the HDD 25, the RAM 26, and the CPU 27.

  The TPM chip 24 on the server 4 side guarantees the validity of hash value collection by managing the rules when the TPM chip 14 on the customer system 2 side collects hash values by hashing and assigning a signature. is there. Moreover, the TPM chip 24 proves the non-falsification of the rule by checking the current rule and signature as necessary. As a result, the TPM chip 14 ensures that there is no falsification in the rules for collecting hash values by referring to the rules that have been proved to be non-falsified on the TPM chip 24 side. It can also be ensured that the workers in the monitoring center 3 dispatched to the customer system 2 have not been tampered with.

  Further, when the encrypted configuration information transmitted from the customer system 2 is received, the TPM chip 24 decrypts the configuration information. Then, the TPM chip 24 outputs the configuration information obtained by decoding to the CPU 27.

(Configuration of DB device)
The DB device 5 is a database server that stores each data in a storage or the like. As illustrated in FIG. 4, the DB device 5 includes a comparison DB 30 and an accumulation DB 40. The comparison DB 30 stores a list used for determining the configuration change of the customer system 2, failure, normality, and the like. The comparison DB 30 stores a white list 31, a black list 32, a yellow list 33, a verified list 34, an unknown list 35, and a big DB 36.

  In the white list 31, for example, configuration information of normal system configurations that can be combined and guaranteed by the manufacturer at the timing of hardware shipment, software commercialization, patch provision, or the like is registered. The configuration information registered in the white list 31 includes a hash value corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the white list 31 to determine whether the system configuration on the customer system 2 side is a normal system configuration.

  In the black list 32, for example, configuration information corresponding to the system configuration of the failure case verified by the manufacturer is registered. The configuration information registered in the black list 32 includes a hash value corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the black list 32 to determine whether or not the system configuration on the customer system 2 side is the system configuration of the failure case. The verified failure case may include a case in which a verified failure is likely to occur.

  In the yellow list 33, configuration information corresponding to the system configuration of a failure case that does not correspond to the black list 32 but whose cause is unknown and unverified is registered. The configuration information registered in the yellow list 33 includes a hash value corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the yellow list 33 to determine whether or not the system configuration on the customer system 2 side is the system configuration of the failure case whose cause is unknown. Note that failure cases with unknown causes may include cases where there is a high possibility that failures with unknown causes will occur. An example of the first list is a yellow list 33, for example.

  In the verified list 34, configuration information corresponding to a system configuration verified in operation is registered. The configuration information registered in the verified list 34 includes hash values corresponding to the software configuration and the hardware configuration of the system configuration. The server 4 refers to the verified list 34 to determine whether or not the system configuration on the customer system 2 side is a verified system configuration in a normal state. An example of the second list is a verified list 34.

  In the unknown list 35, configuration information corresponding to an unknown system configuration that does not correspond to any of the white list 31, the black list 32, the yellow list 33, and the verified list 34 is registered. An example of the third list is an unknown list 35, for example.

  The big DB 36 is a database that stores information collected from each customer system 2. FIG. 5 is an explanatory diagram schematically showing an example of a table configuration of a big DB. In the big DB 36 shown in FIG. 5, the configuration information 36A collected from each customer system 2 is associated with a system ID 36B for identifying the customer system 2 and time information 36C such as a date when the configuration information 36A is collected. Data is stored. An example of the storage unit is a big DB 36, for example.

  The storage DB 40 is a DB that sequentially stores configuration information collected from each customer system 2 for each customer system 2. FIG. 6 is an explanatory diagram illustrating an example of a table configuration of the storage DB. The storage DB 40 illustrated in FIG. 6 stores the date 41, the system ID 42, the location ID 43, the representative hash value 44, and the hash value 45 in association with each other. The date 41 is, for example, the date when the configuration information is collected from the customer system 2 on the server 4 side. The system ID 42 is an ID for identifying the customer system 2 that is the transmission source of the configuration information. The location ID 43 is an ID indicating the installation location of the customer system 2 that is the transmission source. The representative hash value 44 is a representative hash value in the configuration information. The hash value 45 is a hash value of the software configuration and the hardware configuration in the configuration information.

(Configuration of fault monitoring device)
The failure monitoring device 6 is a server device that notifies the server 4 of failure case information. The failure case information includes the failure content and, for example, a hash value of a software configuration and / or a hardware configuration corresponding to the system configuration of the failure. Since this failure monitoring device 6 has the same configuration as a general server device, detailed description thereof is omitted here. However, the configuration of the failure monitoring device 6 is not limited to the configuration of a general server device, and the case information of the failure may be notified to the server 4 using the TPM chip as in the customer system 2 and the server 4. it can.

[Server processing]
Next, each process executed by the CPU 27 of the server 4 will be described. Here, a failure determination process, a list update process, and a list determination process will be described.

(Failure judgment process)
FIG. 7 is an explanatory diagram illustrating an example of a failure determination process executed by the CPU in the server. The CPU 27 reads out a failure determination program stored in the HDD 25, executes a failure determination process based on the failure determination program, and performs a configuration information collection unit 51, a configuration change determination unit 52, a configuration change notification unit 53, a failure determination unit 54, a failure The notification unit 55 is executed as a function. The configuration information collection unit 51 collects the configuration information of the customer system 2 decrypted by the TPM chip 24. The configuration information collection unit 51 stores the collected configuration information 36A in the big DB 36 in association with the system ID 36B and acquisition date (time information) 36C of the customer system 2.

  The configuration change determination unit 52 includes a representative hash comparison unit 52A. The representative hash comparison unit 52A refers to the storage DB 40 and determines whether or not there is the same system ID 42 and the same representative hash value 44 as the representative hash value in the decrypted configuration information.

  The configuration change determination unit 52 refers to the storage DB 40 based on the comparison result of the representative hash comparison unit 52A. If there is the same system ID 42 as the corresponding representative hash value and the same representative hash value, the configuration change determination unit 52 includes the current configuration information. It is determined that there is no configuration change of the customer system 2 concerned. The configuration change determination unit 52 refers to the storage DB 40 based on the comparison result of the representative hash comparison unit 52A. If the system ID 42 is the same as the representative hash value and there is no same representative hash value, the configuration change determination unit 52 includes the current configuration information. It is determined that there is a configuration change of the customer system 2 concerned.

  When there is a configuration change, the configuration change notification unit 53 notifies the display unit 22 that there is a configuration change. The administrator of the server 4 can recognize the configuration change of the customer system on the display unit 22. Further, the configuration change notification unit 53 notifies other processes and the like of the occurrence of the configuration change and the information specifying the customer system 2 in which the configuration change has occurred.

  The failure determination unit 54 includes a hash comparison unit 54A. The hash comparison unit 54A refers to the storage DB 40 and determines whether there is a hash value identical to the hash value in the decrypted configuration information. The failure determination unit 54 determines whether the hash value in the configuration information is in the white list 31 through the hash comparison unit 54A. If the hash value is in the white list 31, the customer system 2 is in a normal state system. It is determined as a configuration. The failure determination unit 54 determines whether or not the hash value in the configuration information is in the black list 32 through the hash comparison unit 54A. If the hash value is in the black list 32, the customer system 2 is the system of the failure case. It is determined as a configuration. The failure determination unit 54 determines whether or not the hash value in the configuration information is in the yellow list 33 through the hash comparison unit 54A. If the hash value is in the yellow list 33, the customer system 2 has a failure whose cause is unknown. Determine the system configuration of the case.

  The failure determination unit 54 determines whether the hash value in the configuration information is in the verified list 34 through the hash comparison unit 54A. If the hash value is in the verified list 34, the customer system 2 has been verified. It is determined that the system configuration is normal. When the hash value in the configuration information is not in any of the white list 31, the black list 32, the yellow list 33, and the verified list 34, the failure determination unit 54 determines this configuration information as an unknown system configuration.

  When determining that the hash value in the configuration information is an unknown system configuration, the failure determination unit 54 registers the configuration information in the unknown list 35.

  In addition, when the failure determination unit 54 determines that the system configuration of the verified failure case is detected, the failure notification unit 55 notifies and outputs a black warning indicating that it is included in the black list on the display unit 22. Further, when the failure determination unit 54 determines that the system configuration of the failure case of unknown cause is detected, the failure notification unit 55 notifies and outputs a yellow warning indicating that it is included in the yellow list on the display unit 22.

(List update process)
FIG. 8 is an explanatory diagram showing an example of a list update process executed by the CPU in the server. The CPU 27 reads the list update program stored in the HDD 25, executes the list update process based on the list update program, and executes the list update unit 61, the failure information acquisition unit 62, and the condition policy management unit 63 as functions.

  The failure information acquisition unit 62 acquires failure case information from the failure monitoring device 6. When the configuration information corresponding to the configuration information in the failure case information is in the unknown list 35, the list update unit 61 counts the number of cases for each configuration information and stores the number of cases in the case list 35A. When the configuration information corresponding to the configuration information in the failure case information is in the verified list 34, the list update unit 61 counts the number of cases for each configuration information and stores the number of cases in the case list 34A. When the configuration information corresponding to the configuration information in the failure case information is in the yellow list 33, the list update unit 61 counts the number of cases for each configuration information and stores the number of cases in the case list 33A.

  The list update unit 61 is an example of an update unit, and includes an unknown determination unit 61A, a verified determination unit 61B, and a yellow determination unit 61C. The unknown determination unit 61A refers to the case list 35A in the unknown list 35 and determines whether or not the configuration information in the unknown list 35 satisfies a condition for shifting to the verified list 34. When the configuration information in the unknown list 35 satisfies the condition for shifting to the verified list 34, the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the verified list 34. The condition for shifting from the unknown list 35 to the verified list 34 is when the number of cases of failure (number of occurrences) of the configuration information in the unknown list 35 is less than the second specified number of times within a predetermined period.

  The unknown determination unit 61A refers to the case list 35A in the unknown list 35 and determines whether or not the configuration information in the unknown list 35 satisfies the condition for shifting to the yellow list 33. When the configuration information in the unknown list 35 satisfies the condition for shifting to the yellow list 33, the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the yellow list 33. The condition for shifting from the unknown list 35 to the yellow list 33 is when the number of cases (number of occurrences) of failure cases in the configuration information in the unknown list 35 exceeds the first specified number of times within a predetermined period. The first specified number of times is equal to or greater than the second specified number of times. The first specified number of times is, for example, a number of times corresponding to 20% of the number of failure cases of the configuration information with respect to the total number of the same configuration information registered in the unknown list 35 within a predetermined period.

  The verified determination unit 61B refers to the case list 34A in the verified list 34 and determines whether or not the configuration information in the verified list 34 satisfies the condition for shifting to the yellow list 33. When the configuration information in the verified list 34 satisfies the condition for shifting to the yellow list 33, the verified determination unit 61B deletes the corresponding configuration information from the verified list 34 and registers it in the yellow list 33. The condition for shifting from the verified list 34 to the yellow list 33 is when the number of cases (occurrence number) of the configuration information in the verified list 34 exceeds the first specified number of times within a predetermined period. .

  The yellow determination unit 61C refers to the case list 33A in the yellow list 33 and determines whether or not the configuration information in the yellow list 33 satisfies a condition for shifting to the verified list 34. When the configuration information in the yellow list 33 satisfies the condition for shifting to the verified list 34, the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the verified list 34. The condition for shifting from the yellow list 33 to the verified list 34 is when the number of cases (occurrence number) of the configuration information in the yellow list 33 is less than the second specified number of times within a predetermined period.

  The yellow determination unit 61C refers to the case list 33A in the yellow list 33 and determines whether or not the configuration information in the yellow list 33 satisfies a condition for shifting to the black list 32. When the configuration information in the yellow list 33 satisfies the condition for shifting to the black list 32, the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the black list 32. The condition for shifting from the yellow list 33 to the black list 32 is when the number of cases (occurrence number) of the configuration information in the yellow list 33 exceeds the third specified number of times within a predetermined period. The third specified number of times is greater than the first specified number of times.

  The condition policy management unit 63 manages conditions for transferring configuration information among the unknown list 35, the yellow list 33, and the verified list 34.

  In addition, when the list update unit 61 receives a notification of configuration information in which risk information such as a security hole has been found from the manufacturer side device 100, the list update unit 61 determines whether the corresponding configuration information is registered in the white list 31. To do. Then, when the corresponding configuration information is registered in the white list 31, the list update unit 61 moves the configuration information to the black list 31 or the yellow list 33. Then, for example, the list update unit 61 notifies the list determination unit 71 and the like described later of the moved configuration information and the system ID of the system having the configuration information.

  As an example, the list updating unit 61 moves the detected risk information to the black list 32 when the risk is high, and moves it to the yellow list 33 when the risk is low. Note that high risk corresponds to, for example, a case where early update is recommended or a case where damage by a virus using a detected security hole has already been reported. The low risk corresponds to, for example, a case where the number of days since the discovery is short or a case where a virus removal method using the discovered security hole is disclosed.

(List judgment process)
FIG. 9 is an explanatory diagram illustrating an example of a list determination process executed by the CPU in the server. The CPU 27 reads the list determination program stored in the HDD 25, executes a list determination process based on the list determination program, and executes the list determination unit 71 as a function.

  The list determination unit 71 is an example of a determination unit, and includes a movement detection unit 71a and a danger notification unit 71b. The movement detection unit 71 a detects the movement of configuration information from the white list 31 to the black list 32 or the yellow list 33.

  For example, the movement detection unit 71a detects that a movement has occurred when the movement is generated from the list update unit 61 and the moved configuration information, and refers to the black list 32 or the yellow list 33. The moved configuration information is specified. The movement detection unit 71a can also detect movement by monitoring each of the white list 31, the black list 32, and the yellow list 33.

  As a more detailed example, the movement detection unit 71a detects a list update by monitoring a file access command to each list. At this time, the TPM chip 24 guarantees the operation of the movement detection unit 71a that functions as a watcher. In this way, the movement detection unit 71a can exclude an unauthorized access command from a detection target and detect a normal access command.

  The danger notification unit 71b sequentially refers to the configuration information of the electronic device stored in the storage DB 40 for the electronic device having the configuration information detected by the list determination unit 71, and the configuration information corresponding to the white list 31 And the detected configuration information is notified to the maintenance terminal 400. For example, the danger notification unit 71b refers to the hash values stored in the storage DB 40 in order from the newest one using the system ID of the customer system 2 having the hash value moved to the black list 32 or the yellow list 33 as a key.

  When the hash value corresponding to the system ID is detected, the danger notification unit 71b refers to each list and determines which list the hash value is registered. Subsequently, when the hash value is registered in the white list 31, the danger notification unit 71b notifies the maintenance terminal 400 of the hash value and the system ID.

  On the other hand, when the hash value is registered in a list other than the white list 31, the danger notification unit 71b refers to the storage DB 40 again and searches for a new hash value. Thereafter, the danger notifying unit 71b repeats the same processing until it can be searched that it is registered in the white list 31.

  Here, the danger notification unit 71b can change the notified content depending on whether the destination of the hash value is the black list 32 or the yellow list 33. Specifically, when the destination is the black list 32, the danger notification unit 71b transmits an urgent message because the danger is high. For example, the danger notification unit 71b acquires a countermeasure method from the manufacturer side device 100 and notifies the maintenance terminal 400 of the countermeasure method. As another example, when the cause is a security hole or the like and a patch or the like is disclosed, the danger notification unit 71b may transmit the patch to the corresponding system.

  Further, when the destination of the hash value is the yellow list 33, it is possible that the handling method has not been established although the risk is high. For this reason, since the cause is unknown, the danger notifying unit 71b transmits a message that prompts the user to return to a state that can be registered in the white list 31, and a message that indicates the danger of leaving it unattended. As another example, the danger notification unit 71b can also acquire and notify the method actually handled by another system registered in the yellow list 33 from a maintenance person or the like of each system.

  The message shown here is merely an example, and the present invention is not limited to this. For example, it can be changed based on the cause of the movement to the black list 32 or the yellow list 33. For example, the danger notification unit 71b can also notify an urgent message when the corresponding electronic device is frequently used in the system. In addition, the danger notification unit 71b can also notify an urgent message when the corresponding electronic device is a highly versatile electronic device used in another system.

  Here, the danger notification unit 71b searches the configuration information registered in the white list 31 with the previous configuration information of the system for the customer system 2 having the configuration information moved to the black list 32 or the yellow list 33. However, the present invention is not limited to this. For example, the danger notification unit 71b may search from the verified list 34 or the unknown list 35.

[Processing operation]
Next, processing operations executed in each process described above will be described. Here, a configuration change check process, a failure determination process, an unknown list determination process, a yellow list determination process, a verified list determination process, a list determination process, and a danger notification process will be described.

(Configuration change check process)
FIG. 10 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the configuration change check process. The configuration change check process shown in FIG. 10 is a process of checking whether there is a configuration change of the customer system 2 based on the representative hash value in the configuration information collected from the customer system 2. 10, the configuration information collection unit 51 in the CPU 27 determines whether or not representative hash values have been collected from the customer system 2 (step S11). When the configuration information collection unit 51 collects the representative hash value (Yes at Step S11), the configuration information collection unit 51 proceeds to the next step.

  The representative hash comparison unit 52A determines whether or not the same system ID as the acquired representative hash value and the same representative hash value exist in the storage DB 40 (step S12). When there is the same system ID and the same representative hash value (Yes at Step S12), the configuration change determination unit 52 determines that there is no configuration change of the system configuration related to the representative hash value (Step S13). Furthermore, if the configuration change determination unit 52 determines that there is no configuration change of the system configuration, the configuration change determination unit 52 registers the configuration information of the customer system 2 in the storage DB 40 (step S14), and ends the processing operation illustrated in FIG.

  Also, the representative hash comparison unit 52A determines that there is a configuration change of the system configuration when the same system ID as the acquired representative hash value and the same representative hash value are not in the storage DB 40 (No in step S12). (Step S15). When the configuration change notification unit 53 determines that there is a configuration change in the system configuration, the configuration change notification unit 53 outputs a notification of the configuration change to the display unit 22 (step S16), and registers the configuration information of the system configuration in the storage DB 40. The process proceeds to step S15. As a result, the administrator of the server 4 can recognize that there is a configuration change by looking at the notification content on the display unit 22, for example.

  Further, when the configuration information collection unit 51 has not acquired the representative hash value (No at Step S11), the processing operation illustrated in FIG.

  When the CPU 27 of the configuration change check process shown in FIG. 10 acquires the representative hash value in the configuration information from the customer system 2, the same system ID as the representative hash value and the same representative hash value are in the storage DB 40. It is determined whether or not. If the same system ID and the same representative hash value are in the storage DB 40, the CPU 27 determines that there is no configuration change in the system configuration of the customer system 2.

  Further, if the system ID that is the same as the acquired representative hash value and the same representative hash value is not in the storage DB 40, the CPU 27 determines that the system configuration of the customer system 2 has been changed, and displays that there has been a configuration change. A notification is output to the unit 22. As a result, the administrator of the server 4 can recognize that there is a configuration change in the system configuration of the customer system 2 based on the notification content.

(Failure judgment processing)
FIG. 11 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the failure determination process. The failure determination process illustrated in FIG. 11 is a process of notifying the display unit of the presence or absence of a failure according to the determination result of the failure determination unit 54. In FIG. 11, the configuration information collection unit 51 determines whether or not representative hash values have been collected from the customer system 2 (step S21). When the configuration information collection unit 51 collects the representative hash value (Yes at Step S21), the configuration information collection unit 51 proceeds to the next step.

  Subsequently, the failure determination unit 54 refers to the storage DB 40, extracts the hash value acquired last time, and compares it with the hash value acquired this time to determine whether there is a change (step S22). If the failure determination unit 54 determines that there is a change (Yes at Step S22), the failure determination unit 54 determines whether or not the acquired hash value is in the white list 31 (Step S23). If the failure determination unit 54 determines that there is no change (No at Step S22), the failure determination unit 54 determines that the failure has been determined because the configuration has not been changed, and ends the processing operation illustrated in FIG.

  If the hash value is in the white list 31 (Yes at Step S23), the failure determination unit 54 ends the processing operation illustrated in FIG. 11 because the system configuration is normal. If the hash value is not in the white list 31 (No at Step S23), the failure determination unit 54 determines whether the hash value is in the verified list 34 (Step S24). If the hash value is in the verified list 34 (Yes in step S24), the failure determination unit 54 ends the processing operation illustrated in FIG. 11 because the system configuration is in a verified normal state.

  If the hash value is not in the verified list 34 (No at Step S25), the failure determination unit 54 determines whether or not the acquired hash value is in the yellow list 33 (Step S25). When the hash value is in the yellow list 33 (Yes at Step S25), the failure determination unit 54 notifies the yellow warning to the display unit 22 through the failure notification unit 55 because the system configuration is a failure case whose cause is unknown ( Step S26), the processing operation shown in FIG. 11 is terminated. Note that the administrator of the server 4 can recognize that the system configuration of the customer system 2 is an unknown failure case in response to the yellow warning.

  If the hash value is not in the yellow list 33 (No at Step S25), the failure determination unit 54 determines whether the hash value is in the black list 32 (Step S27). When the hash value is in the black list 32 (Yes at Step S27), the failure determination unit 54 notifies the failure warning unit 55 of a black warning to the display unit 22 because the system configuration is a verified failure case ( Step S28), the processing operation shown in FIG. The administrator of the server 4 can recognize that the system configuration of the customer system 2 has been verified according to the black warning.

  Further, when the hash value is not in the black list 32 (No at Step S27), the failure determination unit 54 registers the configuration information acquired at Step S21 in the unknown list 35 (Step S29), and performs the processing operation illustrated in FIG. finish.

  As described above, when the hash value in the configuration information collected from the customer system 2 is in the white list 31, the notification processing CPU 27 shown in FIG. 11 determines that the system configuration of the customer system 2 is in a normal state.

  When the hash value in the configuration information collected from the customer system 2 is in the verified list 34, the CPU 27 determines that the system configuration of the customer system 2 is in a verified normal state.

  If the hash value in the configuration information collected from the customer system 2 is in the yellow list 33, the CPU 27 determines that the system configuration of the customer system 2 is a failure case whose cause is unknown, and outputs a yellow warning to the display unit 22. . As a result, the administrator of the server 4 can recognize that the system configuration of the customer system is an unknown failure case based on the yellow warning.

  When the hash value in the configuration information collected from the customer system 2 is in the black list 32, the CPU 27 determines that the system configuration of the customer system 2 has been verified as a failure case and outputs a black warning to the display unit 22. . As a result, the administrator of the server 4 can recognize the system configuration of the customer system as a failure case based on the black warning.

(Unknown list determination process)
FIG. 12 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the unknown list determination process. The unknown list determination process shown in FIG. 12 is a process of deleting the configuration information registered in the unknown list 35 and registering it in the yellow list 33 or the verified list 34 in accordance with the migration condition.

  In FIG. 12, the unknown determination unit 61A in the CPU 27 determines whether or not the number of cases of configuration information in the unknown list 35 (for example, the number of occurrences of cases) has exceeded a first specified number of times within a predetermined period ( Step S31). When the number of case examples of the configuration information exceeds the first specified number of times within a predetermined period (Yes at Step S31), the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the yellow list 33 ( Step S32), the processing operation shown in FIG.

  When the number of case examples of the configuration information does not exceed the first specified number of times within a predetermined period (No at Step S31), the unknown determination unit 61A determines that the number of case examples of the configuration information in the unknown list 35 is within the predetermined period. It is determined whether or not the number is less than the prescribed number (step S33). When the number of case examples of the configuration information is less than the second specified number of times within a predetermined period (Yes at Step S33), the unknown determination unit 61A deletes the corresponding configuration information from the unknown list 35 and registers it in the verified list 34 ( Step S34), the processing operation shown in FIG.

  When the number of case examples of the configuration information is not less than the second specified number of times within a predetermined period (No at Step S33), the unknown determination unit 61A ends the processing operation illustrated in FIG.

  As described above, the CPU 27 of the unknown list determination process shown in FIG. 12 deletes the corresponding configuration information from the unknown list 35 when the number of cases of the configuration information in the unknown list 35 exceeds the first specified number of times within a predetermined period. And registered in the yellow list 33. As a result, the configuration information can be dynamically transferred between the unknown list 35 and the yellow list 33.

  When the number of cases of the configuration information in the unknown list 35 is less than the second specified number of times within a predetermined period, the CPU 27 deletes the corresponding configuration information from the unknown list 35 and registers it in the verified list 34. As a result, the configuration information can be dynamically transferred between the unknown list 35 and the verified list 34.

(Yellow list judgment processing)
FIG. 13 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the yellow list determination processing. The yellow list determination process shown in FIG. 13 is a process of deleting the configuration information registered in the yellow list 33 and registering it in the verified list 34 or the black list 32 in accordance with the migration condition.

  In FIG. 13, the yellow determination unit 61C in the CPU 27 determines whether or not the number of cases of the configuration information in the yellow list 33 has exceeded the third specified number of times within a predetermined period (step S41). When the number of case examples of the configuration information exceeds the third specified number of times within a predetermined period (Yes at Step S41), the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the black list 32 ( Step S42), the processing operation shown in FIG.

  In addition, when the number of case examples of the configuration information does not exceed the third specified number of times within the predetermined period (No at Step S41), the yellow determination unit 61C determines that the number of case examples of the configuration information in the yellow list 33 is within the predetermined period. It is determined whether or not the number is less than the prescribed number of times 2 (step S43). When the number of case examples of the configuration information is less than the second specified number of times within a predetermined period (Yes at Step S43), the yellow determination unit 61C deletes the corresponding configuration information from the yellow list 33 and registers it in the verified list 34 ( Step S44), the processing operation shown in FIG.

  If the number of case examples of the configuration information is not less than the second specified number of times within a predetermined period (No at Step S43), the yellow determination unit 61C ends the processing operation illustrated in FIG.

  As described above, the CPU 27 of the yellow list determination process shown in FIG. 13 deletes the corresponding configuration information from the yellow list 33 when the number of cases of the configuration information in the yellow list 33 is less than the second specified number of times within a predetermined period. Registered in the verified list 34. As a result, the configuration information can be dynamically transferred between the verified list 34 and the yellow list 33.

  When the number of cases of the configuration information in the yellow list 33 exceeds the third specified number of times within a predetermined period, the CPU 27 deletes the corresponding configuration information from the yellow list 33 and registers it in the black list 32. As a result, configuration information can be dynamically transferred between the black list 32 and the yellow list 33.

(Verified list judgment processing)
FIG. 14 is a flowchart illustrating an example of the processing operation of the CPU 27 in the server 4 related to the verified list determination process. The verified list determination process shown in FIG. 14 is a process of deleting the configuration information registered in the verified list 34 and registering it in the yellow list 33 according to a predetermined condition.

  In FIG. 14, the verified determination unit 61B in the CPU 27 determines whether or not the number of cases of the configuration information in the verified list 34 has exceeded the first specified number of times within a predetermined period (step S51). The verified determination unit 61B deletes the corresponding configuration information from the verified list 34 and registers it in the yellow list 33 when the number of cases of the configuration information exceeds the first specified number of times within a predetermined period (Yes in step S51). Then (step S52), the processing operation shown in FIG.

  The verified determination unit 61B ends the processing operation illustrated in FIG. 14 when the number of case examples of the configuration information does not exceed the first specified number of times within a predetermined period (No in step S51).

  As described above, when the number of cases of the configuration information in the verified list 34 exceeds the first specified number of times within a predetermined period, the CPU 27 of the verified list determination process shown in FIG. It is deleted from 34 and registered in the yellow list 33. As a result, the configuration information can be dynamically transferred between the verified list 34 and the yellow list 33.

(List judgment processing)
FIG. 15 is a flowchart showing an example of the processing operation of the CPU 27 in the server 4 related to the list determination processing. The list determination process shown in FIG. 15 is a process for newly adding configuration information to the black list 32 in accordance with a predetermined condition. The list determination process is a process for moving the configuration information registered in the white list 31 to the black list 32 or the yellow list 33 according to a predetermined condition.

  As shown in FIG. 15, when the list update unit 61 receives a registration request to the list from the manufacturer side device 100 or the like, the list update unit 61 determines whether or not the request is a new registration to the black list 32 (step S61). Then, if it is a new registration to the black list 32 (Yes at Step S61), the list update unit 61 registers the configuration information received together with the request to the black list 32 (Step S62).

  On the other hand, if the list update unit 61 determines that the registration request to the list is not a new registration to the black list 32 (No in step S62), the list update unit 61 determines whether or not the request is a movement request from the white list 31 to another list ( Step S63).

  If the list update unit 61 determines that the request is for moving from the white list 31 to another list (Yes in step S63), the list update unit 61 replaces the corresponding configuration information registered in the white list 31 with the black specified in the request. It is registered in the list 32 or the yellow list 33 (step S64). If the list update unit 61 determines that the request is not a movement request from the white list 31 to another list (No in step S63), the process ends.

(Danger notification process)
FIG. 16 is a flowchart illustrating an example of the processing operation of the CPU 27 in the server 4 related to the danger notification process. The danger notification process illustrated in FIG. 16 is a process of notifying the display unit 22 of a warning message or the like when it is detected that the configuration information registered in the white list 31 has moved to the black list 32 or the yellow list 33.

  As illustrated in FIG. 16, when the danger notification unit 71b detects that the list is updated by the movement detection unit 71a (Yes in step S71), the danger notification unit 71b extracts the customer system 2 having the newly registered configuration information. (Step S72). Specifically, when it is detected that the configuration information registered in the white list 31 has moved to the black list 32 or the yellow list 33, the danger notification unit 71b refers to the storage DB 40 or the like and has moved. The customer system 2 having the configuration information is specified.

  Subsequently, the danger notification unit 71b extracts the configuration information at the time of the previous reception of the extracted customer system 2 from the storage DB 40, and executes list determination to determine in which list the extracted configuration information is registered. (Step S73).

  Thereafter, when it is determined that the configuration information is registered in a list other than the yellow list 33 or the black list 32 (Yes at Step S74), the danger notification unit 71b extracts the customer system having the configuration information from the big DB 36. (Step S75). Thereafter, the danger notification unit 71b notifies the extracted customer system of a warning message or the like on the display unit 22 (step S76). That is, although the configuration has not been changed, the customer system 2 whose configuration information has been moved from the white list 31 to the yellow list 33 or the black list 32 is notified of a decrease in security.

  On the other hand, when the danger notifying unit 71b determines that the configuration information is not registered in a list other than the yellow list 33 or the black list 32 (No in step S74), the danger notifying unit 71b refers to the storage DB 40 and continues to the next one. New configuration information is extracted (step S77). Thereafter, the danger notification unit 71b returns to Step S74 and repeats the subsequent processing.

  As described above, in the first embodiment, the system configuration on the customer system 2 side, for example, configuration information including the hash value for each software configuration and hardware configuration is periodically collected, and the configuration information for each customer system 2 is stored in the storage DB 40. Accumulated. As a result, the server 4 can grasp the system configuration for each customer system 2 in time series with reference to the storage DB 40.

  In the first embodiment, as the system configuration on the customer system 2 side, the configuration information including the hash value of the software configuration and the hardware configuration is transmitted to the server 4, so the data amount of the system configuration is the minimum required fixed amount of data amount. Therefore, the bandwidth used for the communication path can be reduced.

  In the first embodiment, the presence / absence of a configuration change on the customer system 2 side is checked by referring to the accumulation DB 40 with a representative hash value in the configuration information. As a result, the presence / absence of the configuration change of the customer system 2 can be checked at high speed.

  In the first embodiment, the content of the failure is detected by comparing the hash value corresponding to the system configuration of the customer system 2 with the hash value registered in each list. As a result, it is possible to realize prior prediction of failure occurrence and early solution after failure occurrence.

  When the hash value in the configuration information collected from the customer system 2 is in the yellow list 33, the server 4 according to the first embodiment determines that the customer system 2 has a system configuration related to a failure case whose cause is unknown. As a result, the server 4 identifies the customer system 2 as a system configuration related to a failure whose cause is unknown.

  When the hash value in the configuration information collected from the customer system 2 is in the verified list 34, the server 4 according to the first embodiment determines that the customer system 2 has a verified normal system configuration. As a result, the server 4 identifies the system configuration as a normal state verified by the customer system 2.

  The server 4 according to the first embodiment can confirm the configuration change by comparing the previous configuration information of the customer system 2 stored in the storage DB 40 and the collected current configuration information with the representative hash value. In addition, when it is confirmed that a failure has occurred due to the current configuration change, the server 4 can recover the failure early by returning to the previous configuration information.

  In the first embodiment, the hash value collection rule and the encryption rule used by the TPM chip 14 on the customer system 2 side and the TPM chip 24 on the server 4 side conform to the internationally published standard specifications, and thus the evidence is also provided. It is expensive and can be independently verified by a third party.

  When the received configuration information is different from the previous configuration information stored in the storage DB 40, the CPU 27 according to the first embodiment compares the configuration information with the configuration information registered in the comparison DB 30.

  Further, the server 4 registers a hash value corresponding to the patch in the white list 31 and determines whether or not there is a patch hash value registered in the white list 31 in the configuration information collected from the customer system 2. May be. In this case, the server 4 can confirm the presence / absence of patch application for each customer system 2.

  For example, the server 4 collects configuration information before applying the patch to the customer system 2 and configuration information after applying the patch, and compares the configuration information before applying the patch with the configuration information after applying the patch to determine whether the patch is applied. Can be confirmed. Moreover, since the server 4 knows the configuration information before applying the patch, it can be returned to the original system configuration by rollback.

  For example, the server 4 registers the white list 31 of the system configuration after completion of the maintenance work, and determines whether or not the hash value in the configuration information collected from the customer system 2 is in the white list 31. As a result, the server 4 can confirm whether or not the maintenance work is completed for each customer system 2.

  In the first embodiment, since the customer system 2 having the configuration information moved from the white list 31 to the black list 32 or the yellow list 33 can be detected, the risk of system abnormality such as a decrease in security is detected at an early stage. be able to. Moreover, danger can be dealt with early and the period during which security is reduced can be minimized.

  Further, it is possible to notify the customer system 2 having the configuration information moved from the white list 31 to the black list 32 about the configuration information of the white list 31 and a coping method already established. Moreover, the coping method which the other customer performed can be notified with respect to the customer system 2 which has the structure information which moved from the white list 31 to the yellow list 33. FIG.

  Therefore, when the configuration information corresponding to the white list 31, the unknown list 35, and the verified list 34 is changed to the black list 32 or the yellow list 33, the customer having the configuration information is specified. An instruction for avoiding being in the black list 32 can be output.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above. Therefore, different embodiments will be described below.

  For example, in the first embodiment, the hardware configuration and the software configuration are included as the system configuration of the customer system 2, but it is proved that the combination of the two is correctly maintained in the work of changing the software version number when replacing the hardware parts. In order to do this, a hash value of the combination may be collected.

  In the failure determination unit 54 of the above embodiment, since the configuration information registered in each list 31 to 35 is a hash value, the state of the system configuration is determined using the hash value, but the representative hash value is included in each list 31 to 35. May be determined by the representative hash value.

  In the above embodiment, a computer device is illustrated as an example of the electronic device of the customer system 2. The electronic device may be, for example, a server, a printer, a network device, an external storage, a mobile phone, a smartphone, a refrigerator, a washing machine, a television, a stereo component, a medical device, a machine tool, or the like.

  The configuration information corresponding to the system configuration of the failure case is registered in the yellow list 33 of the above embodiment. At this time, the configuration information is displayed for each risk level corresponding to the failure state of the failure case. You may register within. The degree of risk corresponding to the failure status is, for example, a plurality of ranks according to the range of influence of the failure caused by the failure case and the amount of damage. At this time, the failure determination unit 54 determines whether the received configuration information has a hash value for each risk level in the yellow list 33, and notifies the yellow warning corresponding to the risk level corresponding to the hash value. Output. As a result, the administrator of the server 4 can recognize a failure case corresponding to the degree of risk.

  In the above-described embodiment, an example in which the customer system having the moved configuration information is specified when the movement of the configuration information is detected has been described. However, the present invention is not limited to this. For example, the monitoring center 3 side receives configuration information from the customer system 2 and determines whether the configuration information is registered in the black list 32 or the yellow list 33. On the monitoring center 3 side, when the received configuration information is registered in the black list 32 or the yellow list 33, the customer system 2 having the configuration information can be specified.

  In addition, among the processes described in the present embodiment, all or a part of the processes described as being automatically performed can be manually performed. Alternatively, all or part of the processing described as being performed manually can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-described document and drawings can be arbitrarily changed unless otherwise specified.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device is not limited to that shown in the figure. That is, all or a part of them can be configured to be functionally or physically distributed / integrated in arbitrary units according to various loads or usage conditions. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

2 Customer system 4 Server 5 DB device 14 TPM chip 24 TPM chip 27 CPU
31 White List 32 Black List 33 Yellow List 34 Verified List 35 Unknown List 36 Big DB
40 Storage DB
52 configuration change determination unit 52A representative hash comparison unit 53 configuration change notification unit 54 failure determination unit 54A hash comparison unit 55 failure notification unit 61 list update unit 61A unknown determination unit 61B verified determination unit 61C yellow determination unit 71 list determination unit 71a movement Detection unit 71b Danger notification unit

Claims (6)

A storage unit for storing configuration information received from the electronic device;
A first list storing configuration information indicating that the electronic device is in a first state;
When the configuration information of the electronic device is received, it is determined whether the configuration information is different from the configuration information previously received based on the storage unit. If the configuration information is different, the configuration information stored in the first list is determined. A determination unit for determining whether or not the same,
A detection unit configured to detect, from the storage unit, an electronic device corresponding to the configuration information when the determination unit determines that the configuration information is the same as the configuration information stored in the first list. Management device. The storage unit stores configuration information of the electronic device in time series,
For the electronic device detected by the detection unit, the configuration information indicating that the electronic device is in the second state is stored by sequentially referring to the configuration information of the electronic device stored in the storage unit. The management apparatus according to claim 1, further comprising an information notification unit that detects configuration information corresponding to the second list and notifies the detected configuration information to a maintenance terminal of the electronic device.   In response to the degree of the state of the electronic device indicated by the first list, a notification of change that notifies the maintenance terminal of the electronic device that is detected by the detection unit and that notifies the change of the content corresponding to the state The management apparatus according to claim 1, further comprising a unit.   When the state of the electronic device indicated by the first list has been verified by the manufacturer of the electronic device, the countermeasure notification unit notifies the maintenance terminal of the electronic device of a countermeasure that can eliminate the state. When the state of the electronic device indicated by the first list is unknown and unverified, the maintenance method of the electronic device is notified of a countermeasure that has been implemented for the state. The management apparatus according to claim 3. Computer
When the configuration information of the electronic device is received, it is determined whether the configuration information of the electronic device is different from the configuration information previously received based on the storage unit. It is determined whether the configuration information is the same as the configuration information stored in the first list that stores the configuration information indicating the state of
When it is determined that the configuration information is the same as the configuration information stored in the first list, a process for detecting an electronic device corresponding to the configuration information from the storage unit is executed. On the computer,
When the configuration information of the electronic device is received, it is determined whether the configuration information of the electronic device is different from the configuration information previously received based on the storage unit. It is determined whether the configuration information is the same as the configuration information stored in the first list that stores the configuration information indicating the state of
When it is determined that the configuration information is the same as the configuration information stored in the first list, a management program for executing processing for detecting an electronic device corresponding to the configuration information from the storage unit.

Images